+<p>Since version 0.4.0, rEFInd has shipped with a small collection of read-only EFI filesystem drivers. These are:</p>
+
+<ul>
+
+<li><b>Ext2fs</b>—This driver originated with rEFIt. It's useful for
+ reading Linux kernels from a separate <tt>/boot</tt> partition, or even
+ from a root (<tt>/</tt>) filesystem, if you use ext2fs on it. Although
+ it's called an "ext2fs" driver, it also works with ext3fs.</li>
+
+<li><b>Ext4fs</b>—Stefan Agner <a
+ href="https://github.com/falstaff84/rEFInd">modified the rEFIt/rEFInd
+ ext2fs driver</a> so that it could handle ext4fs. I'm including this as
+ a separate driver from the ext2fs driver, although the ext4fs version
+ can handle ext2fs and ext3fs, too. Providing both drivers enables easy
+ filesystem separation—for instance, you can use ext2fs on a
+ <tt>/boot</tt> partition and ext4fs on your root (<tt>/</tt>) partition,
+ to have the EFI scan only the former. This driver has some limitations
+ and may not work with all ext4 filesystems. Although it supports (as of
+ version 0.10.4) 64-bit pointers, this support is untested on over-16TiB
+ volumes. As of version 0.6.1, this driver supports the <tt>meta_bg</tt>
+ feature, which can also be used on ext2fs and ext3fs. Thus, it can
+ handle some ext2fs and ext3fs partitions that the ext2fs driver can't
+ handle. You can learn about your ext2/3/4 filesystem features by typing
+ <tt class="userinput">dumpe2fs <i>/dev/sda2</i> | grep features</tt>,
+ changing <tt class="userinput"><i>/dev/sda2</i></tt> to your
+ filesystem's device.</li>
+
+<li><b>ReiserFS</b>—This driver originated with rEFIt. It can be used
+ in the same way as the ext2fs and ext4fs drivers. <b>Caution:</b> If you
+ use this driver, you should use the <tt>notail</tt> option in Linux's
+ <tt>/etc/fstab</tt> file for the partition(s) you want the EFI to read.
+ This is because the driver doesn't properly handle ReiserFS's
+ "tail-packing" feature, so files can seem to be corrupted in EFI if you
+ use this feature, which is disabled by <tt>notail</tt>. In my tests,
+ this is the fastest of rEFInd's EFI filesystem drivers, so if you find
+ your kernel load times are slow, you might consider moving your kernel
+ to a ReiserFS <tt>/boot</tt> partition. (Such problems affect a small
+ subset of EFI-based computers.)</li>
+
+<li><b>Btrfs</b>—</b>Samuel Liao contributed this driver, which is
+ based on the rEFIt/rEFInd driver framework and algorithms from the GRUB
+ 2.0 Btrfs driver. I've tested this driver with simple one-partition
+ filesystems on several installations, and with a filesystem that spans
+ two physical devices on one (although I've made no attempt to ensure
+ that the driver can actually read files that span both devices). Samuel
+ Liao has used the driver with a compressed Btrfs volume. The driver will
+ handle subvolumes, but you may need to add kernel options if you're
+ booting a Linux kernel directly from a filesystem that uses subvolumes.
+ For instance, when booting Ubuntu from Btrfs, <tt>also_scan_dirs +
+ @/boot</tt> must be set in <tt>refind.conf</tt> and
+ <tt>rootflags=subvol=@</tt> must be added to the kernel options in
+ <tt>refind_linux.conf</tt>. Without the first of these options, rEFInd
+ can not locate the kernel; and without the second, the boot fails with a
+ message to the effect that the initial RAM disk could not find
+ <tt>/sbin/init</tt>. rEFInd 0.10.0 adds <tt>@/boot</tt> as a standard
+ option to <tt>also_scan_dirs</tt>, and its <tt>refind-install</tt> and
+ <tt>mkrlconf</tt> scripts should pick up the root flags, assuming the
+ system is booted into the regular installation. These additions make it
+ easier to set up rEFInd to work with Btrfs.</li>
+
+<p class="sidebar"><b>Tip:</b> If you partition a USB flash drive and use <tt>dd</tt> to copy Linux <tt>.iso</tt> images to the drive's individual partitions, the rEFInd ISO-9660 driver enables rEFInd to boot multiple Linux distributions' installers from the USB flash drive. I can't promise this feature will work with all distributions, but it does work with some.</p>
+
+<li><b>ISO-9660</b>—This driver originated with rEFIt's author, but
+ he never released a final version. Its code was improved by Oracle for
+ use in its VirtualBox product, and then further modified by the authors
+ of the <a
+ href="https://sourceforge.net/projects/cloverefiboot/">Clover</a> boot
+ loader. If your firmware doesn't provide its own ISO-9660 driver, this
+ one can be helpful; however, you may need to install it on your hard
+ disk before you can read an optical disc.</li>
+
+<li><b>HFS+</b>—Oracle wrote this driver, apparently with some code
+ taken from open source Apple examples. It was then further modified by
+ the Clover authors. I expect this driver to have limited appeal to most
+ rEFInd users. Macs don't need it, since Apple's EFI implementation
+ provides its own HFS+ driver, and HFS+ isn't normally used on
+ UEFI-based PCs. Some CDs are mastered with both ISO-9660 and HFS+, or
+ even with HFS+ alone, and it's conceivable that an HFS+ driver would be
+ useful when accessing such discs. Also, one unusual feature of this
+ driver is that it can read files from within an Apple LVM setup, which
+ Apple's own EFI HFS+ driver can't do. The upshot of this feature is
+ that if you load this driver on a Mac that uses Apple's LVM, rEFInd is
+ likely to show two OS X boot options. Ordinarily this is pointless, but
+ it could be helpful if your Recovery HD volume becomes damaged. I'm
+ providing the driver mainly because it compiled cleanly with no extra
+ work, aside from providing a Makefile entry for it.</li>
+
+<p class="sidebar"><b>Warning:</b> I've received multiple reports of system hangs when using the NTFS driver; however, I've been unable to replicate the problem. (The problem is probably triggered either by interactions with specific EFIs or by unique features of the "problem" NTFS volumes.) I therefore recommend avoiding the NTFS driver unless it's absolutely necessary. Various rEFInd versions include fixes intended to address this problem, but I can't be sure it's been completely eliminated.</p>
+
+<li><b>NTFS</b>—Samuel Liao contributed this driver, which uses the
+ rEFIt/rEFInd driver framework. Note that this driver is
+ <i><b>not</b></i> required to boot Windows with rEFInd, since Windows
+ stores its EFI boot loader on the (FAT) ESP, and the BIOS boot process
+ (generally used when dual-booting on a Mac) relies only on the
+ partition's boot sector, which is read without the benefit of this
+ driver. Reasons to use this driver include:
+ <ul>
+ <li>If you want to use Windows to write large files, such as RAM
+ disk images, to be read from EFI.</li>
+ <li>If you have a Mac and NTFS data partitions, loading this driver
+ should exclude those data partitions from the boot menu.</li>
+ <li>If you have a Mac that dual-boots with Windows, using this driver
+ should provide NTFS volume names in the boot menu.</li>
+ </ul>
+ </li>
+
+</ul>
+
+<p>All of these drivers rely on filesystem wrapper code written by rEFIt's author, Christoph Phisterer.</p>
+
+<p>Although Linux filesystems are all case-sensitive, these drivers treat them in a case-insensitive way. Symbolic links work; however, rEFInd 0.6.11 and later ignore symbolic links, since many distributions use them in a way that creates redundant or non-functional entries in the rEFInd menu. You should be able to use hard links if you want to use a single kernel file in multiple ways (say for two distributions).</p>
+
+<a name="finding">