Ext2 Installable File System For Windows

FAQ

Table of contents

What features are supported?

What features are *not* supported?

How are drive letters configured for Ext2 volumes?

Creating, modifying and removing of drive letters is very simple. Please use the "IFS Drives" item, which has been installed on the system's control panel.

icon screenshot

It shows a partition scheme and enables you to administrate drive letters for all non-Windows partitions, including all the Ext2 volumes. (That partition scheme is shown by the setup application of this software package, too.) You must have administrator rights.

Drive letters may also be configured with the Windows mountvol utility. See also section "Can drive letters also be configured from scripts?".

Can drive letters also be configured from scripts?

With version 1.11 of the Ext2 IFS software, drive letters can be configured with the Windows mountvol utility (except on Windows NT 4.0). This is useful if you want to control them from a script.

The mountvol utility is used just as if the drive letters would correspond to native Windows volumes, regardless of whether the volumes are native Windows volumes or Ext2/Ext3 ones.

First create a drive letter, for example X:, for a given Ext2/Ext3 volume with the "IFS Drives" item in the control panel in order to conveniently identify it in the following steps:

Use the Windows mountvol utility in order to identify the persistent volume name of the volume (replace X: with the actual drive letter):
mountvol X:\ /L

Now mountvol will report the persistent volume name (example):
\\?\Volume{241c8cc6-c4e4-11db-8168-c5932447ec37}

The persistent volume name of a native volume of Windows remains valid unless Windows is reinstalled again. The persistent volume name of a volume that is managed by Ext2 IFS remains valid as long as the Ext2 IFS software remains installed.

You can use a known persistent volume name for a specific volume in order to create a new drive letter:
mountvol X:\ \\?\Volume{241c8cc6-c4e4-11db-8168-c5932447ec37}

You can delete a drive letter with
mountvol X:\ /D

Does the Ext2 driver access Ext4 volumes?

Unfortunately the Ext2 driver is not able to access Ext4 volumes at all.

Does the Ext2 driver access Ext3 volumes?

The Ext3 file system is the Ext2 file system which has been extended by journaling. Ext3 is backward-compatible to Ext2 - an Ext3 volume can be mounted and used as an Ext2 volume. Just as older Linux Kernels which do not know the Ext3 file system can mount Ext3 volumes (as Ext2 volumes), the Ext2 file system driver ext2fs.sys for Windows incorporated in this software package can do it without any problems, too. Of course you do not take advantage of the journaling of the Ext3 file system if you mount it as an Ext2 file system.

If you mount an Ext3 file system as an Ext2 file system and the file system is not cleanly dismounted, (e.g. due to a system crash), you have to run the e2fsck tool. (Linux does it automatically.) Running e2fsck can take several hours on large volumes. You do not benefit from journaling the Ext3 file system, because you have to run e2fsck.

If you mount an Ext3 file system as an Ext3 file system (journaling) and the file system is not cleanly dismounted due to a system crash, things are much better: When the volume is mounted next time as an Ext3 file system, a replay of the journal will be done, after which the file system will be consistent. You need not run e2fsck. (If you run e2fsck nevertheless, it won't find any errors of the Ext3 file system, because there will not be any errors after replaying the journal.)

If a volume is mounted as Ext3 file system, any new data is first completely written into the journal, and then into the file system. This is also called a transaction. Finally, the data is removed from the journal. So a journal only contains data when you are writing to the file system. After a clean dismount of the Ext3 file system, the journal is empty.

When the Linux kernel mounts an Ext3 file system, it first checks whether the journal contains complete transactions (not written yet due to a prior crash). If there are any, it does the already mentioned replay of the journal, which means that all data of the journal is written to the file system, and any data will be removed from it. So a replay always repairs any damage caused by a prior crash.

With the described way of writing the journal and the file system's data and with a replay of the journal after a crash, consistency of the file system is always achieved. Thus, e2fsck will not find any error.

The Ext2 file system driver of the Ext2 IFS software will refuse mounting an Ext3 file system which contains data in its journal, just like older Linux kernels which have no Ext3 support. In this way data loss and damaging the file system is avoided when the journal is subsequently replayed. So you can access only those Ext3 volumes with the Ext2 IFS software which have been cleanly dismounted beforehand.

What limitations arise from not maintaining access rights?

The current version of the Ext2 file system driver does not maintain access rights. All users can access all the Ext2 volumes that a drive letter is created for. For example, if a drive letter has been created for an Ext2 volume, which is the root volume of a Linux installation, you can simply read and modify files such as /etc/passwd and /etc/shadow. User names are readable and passwords of these users can be quite easily cracked and modified!

Therefore the current Ext2 file system driver does not fit for installations which require restrictive rights policies. It should be sufficient for your computer at home, which is used by one or a few users only. Furthermore, you should create drive letters for a root volume of a Linux installation only if you know exactly what you are doing.

What Ext2 revisions and Ext2 feature bits does the Ext2 driver support?

Revision 0 (Linux Kernel 2.2 and prior) and revision 1 (dynamic revision, Linux Kernels higher than 2.2) are supported.

Revision 1 (dynamic revision) implements feature bits as a kind of version control. These feature bits indicate whether an Ext2 file system residing on a disk has particular feature properties. Almost all feature bits are determined at the time when the Ext2 file system is created. Therefore most of the possible feature bits correspond to the -O switch of the mke2fs tool of Linux. (mke2fs is the "formatting tool" for Ext2 file system and creates such a file system. There is also a tune2fs tool for modifying feature bits of an Ext2 file system.)

The current version of the Ext2 file system driver (ext2fs.sys version 1.12) supports the following feature bits of the Ext2 file system:

mke2fs -O description
EXT2_FEATURE_COMPAT_DIR_INDEX
dir_index Htree directories. A directory may contain an additional index in order to speed up lookups in large directories.
EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER
sparse_super File system with fewer super block backup copies. (Saves space on large file systems.)
EXT2_FEATURE_RO_COMPAT_LARGE_FILE
large_file Files larger than 2 GBytes are currently stored in the file system. See note#1.
EXT4_FEATURE_RO_COMPAT_HUGE_FILE
huge_file Files larger than 2 TBytes can be stored in the file system; the limit is slightly less than 2 TBytes. See note#2.
EXT4_FEATURE_RO_COMPAT_GDT_CSUM
uninit_bg The block bitmap, inode bitmap, and the inodes of a group can remain uninitialized prior to their first use. Speeds up the creation of the file system by the mke2fs tool. Furthermore, a cyclic redundancy check (CRC) value is added to the group descriptors.
EXT4_FEATURE_RO_COMPAT_DIR_NLINK
dir_nlink 65000 or more subdirectories can be stored within a directory. See note#3.
EXT4_FEATURE_RO_COMPAT_EXTRA_ISIZE
extra_isize Influences how much storage space of an inode is used for particular purposes, for example, extended attributes.
EXT2_FEATURE_INCOMPAT_FILETYPE
filetype File type information is stored in directory entries, too. (Improves performance on querying the content of a directory.)
EXT2_FEATURE_INCOMPAT_META_BG
meta_bg Groups no longer contain the group descriptors of the entire volume. An adequate amountof groups is combined to in a "meta_bg" group. Three of the groups of a "meta_bg" group store group descriptors. The meta_bg feature avoids excessive space allocation for group descriptors on very large volumes.
EXT4_FEATURE_INCOMPAT_FLEX_BG
flex_bg The bitmaps and the inode table of a group no longer need reside in the group itself. Thus, mke2fs may combine a fixed number of groups to a "flex_bg group" and place the bitmaps and inode tables of the "flex_bg group" together in order to improve performance.

Note#1: The EXT2_FEATURE_RO_COMPAT_LARGE_FILE feature is usually disabled when creating an Ext2 file system. It is set on the first store operation for a file larger than 2 GBytes. See next section "What is the Large File Feature and how is it configured?"

Note#2: EXT4_FEATURE_RO_COMPAT_HUGE_FILE is either cleared or set by the mke2fs tool on creation of the Ext2 file system. If it is cleared, any attempt to store a file larger than 2 TBytes fails. The Linux Kernel does *not* set the EXT4_FEATURE_RO_COMPAT_HUGE_FILE feature subsequently. The Ext2 IFS driver can set the EXT4_FEATURE_RO_COMPAT_HUGE_FILE on the first store operation for a file larger than 2 TBytes. See section "What is the Huge File Feature and how is it configured?"

Note#3: The EXT4_FEATURE_RO_COMPAT_DIR_NLINK feature is usually disabled when creating an Ext2 file system. It is set on of the first store operation for 65000 subdirectories. See section "What is the dir_nlink Feature and how is it configured?"

What is the Large File Feature and how is it configured?

Linux kernels version higher than 2.2 allow storing files larger than 2 GBytes on Ext2 volumes: They set a feature bit
EXT2_FEATURE_RO_COMPAT_LARGE_FILE
the first time such a large file is stored.

But this set feature bit causes old Linux Kernels, which do not support large files (version 2.2 or prior), mounting the Ext2 volume as a read-only volume. If that volume is the root volume of an old Linux installation, its Linux Kernel will become inoperable (it will enter the maintenance mode on booting).

The Ext2 file system driver ext2fs.sys for Windows has to behave exactly like Linux kernels to become compatible with the Linux file system Ext2. But the behavior of old and new Linux Kernels regarding to large files excludes each other, so the Ext2 file system driver ext2fs.sys for Windows is configurable whether it behaves like an old Linux Kernel (2.2 or prior) or a new Linux Kernel (higher than 2.2).

The setup wizard of this software asks the user whether the large file feature should be enabled and configures the file system driver ext2fs.sys for Windows according to the choice made by the user. If you have a recent Linux distribution, you should enable the large file feature. If you choose the simple setup option, the large file feature is enabled.

If you want to check or modify whether the large file feature of ext2fs.sys is enabled, it is configured at the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ext2fs\Parameters
by the registry value
TriggerLargeFileFeature

If that (DWORD-) value exists and is not equal to 0x0000 the large file feature is enabled. (Changes will take effect on next reboot.)

What is the Huge File Feature and how is it configured?

Linux kernels version 2.6.19 or higher store files larger than 2 TBytes if they are mounting the volume as Ext4 volume and the feature bit
EXT4_FEATURE_RO_COMPAT_HUGE_FILE
is set.

Setting this feature bit causes old Linux Kernels, which do not support huge files (version prior 2.6.19), to mount the volume as a read-only volume. This also occurs if the Linux Kernel mounts the volume as Ext2 or Ext3. If the volume is the root volume of an old Linux installation, its Linux Kernel will become inoperable (it will enter the maintenance mode on booting).

If the huge file feature is cleared, any attempt to store a file larger than 2 TBytes fails. The Linux Kernel does not set the EXT4_FEATURE_RO_COMPAT_HUGE_FILE feature subsequently. Usually EXT4_FEATURE_RO_COMPAT_HUGE_FILE is either cleared or set by the mke2fs tool on creation of the Ext2 file system.

The Ext2 file system driver ext2fs.sys is able to set the huge file feature, unlike the Linux Kernel.

The setup wizard of this software asks the user whether the huge file feature feature should be enabled and configures the file system driver ext2fs.sys for Windows according to the choice made by the user. If in doubt, disable the huge file feature. If you choose the simple setup option, the huge file feature is disabled.

To check or modify whether the huge file feature of ext2fs.sys is enabled, it is configured at the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ext2fs\Parameters
through the registry value
TriggerHugeFileFeature

If this (DWORD-) value exists and is not equal to 0x0000 the huge file feature is enabled. (Changes will take effect on next reboot.)

What is the dir_nlink Feature and how is it configured?

Linux kernels version 2.6.23 or higher are able to store 65000 or more subdirectories within a directory if they are mounting the volume as Ext4 volume: They set a feature bit
EXT4_FEATURE_RO_COMPAT_DIR_NLINK
the first time 65000 subdirectories are created within a directory.

Setting this feature bit causes old Linux Kernels, which do not support the dir_nlink feature (prior to version 2.6.23), to mount the volume as a read-only volume. This also occurs if the Linux Kernel mounts the volume as Ext2 or Ext3. If the volume is the root volume of an old Linux installation, its Linux Kernel will become inoperable (it will enter the maintenance mode on booting).

The Ext2 file system driver ext2fs.sys for Windows has to behave exactly like Linux kernels to become compatible with the Linux file system Ext2. As the behaviors of old and new Linux Kernels with regard to the dir_nlink feature are mutually exclusive, the Ext2 file system driver ext2fs.sys for Windows is configurable, to behave like an old Linux Kernel (prior 2.6.23) or a new Linux Kernel (2.6.23 or higher).

The setup wizard of this software asks the user whether the dir_nlink feature should be enabled and configures the file system driver ext2fs.sys for Windows according to the choice made by the user. If in doubt, disable the dir_nlink feature. If you choose the simple setup option, the dir_nlink feature is disabled.

To check or modify whether the dir_nlink feature of ext2fs.sys is enabled, it is configured at the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ext2fs\Parameters
through the registry value
TriggerDirNLinkFeature

If this (DWORD-) value exists and is not equal to 0x0000 the large file feature is enabled. (Changes will take effect on next reboot.)

Does the fsutil tool of Windows control the trim support of the Ext2 file system driver?

(Windows 7/Server 2008 R2 or newer.)

No, fsutil does not control the trim support of the Ext2 file system driver. Example for NTFS: If entering
fsutil behavior query disabledeletenotify
at the command prompt yields "DisableDeleteNotify = 0", the trim support for NTFS is enabled in general; trim operations will be performed if there is a solid state drive (SSD) which supports trim operations.

Fsutil merely checks or modifies at the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
the registry value
DisableDeleteNotification

The ext2fs.sys driver of the Ext2 IFS software does not utilize this registry value. If you want to disable the trim support of ext2fs.sys, you can modify at the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ext2fs\Parameters
the registry value
DisableDeleteNotification

If that (DWORD-) value exists and is not equal to 0x0000 the trim support of ext2fs.sys is disabled. (Changes will take effect on next reboot.)

The default is trim support enabled; if in doubt you should not disable it. The ext2 driver does not attempt to issue any trim operation on drives which are not able to perform a trim operation. An unnecessary overhead due to trim operations is avoided in this way.

What about block sizes up to 64KB?

The Ext2/Ext3/EXT4 implementation of the Linux Kernel can access block sizes of the file system up to the page size of the processor architecture. If the file system of a volume has a block size which is larger than the page size, the Linux Kernel can't access the volume. The page size of the Linux Kernel is:

It means that the Linux kernel is not able to access Ext2/Ext3/Ext4 volumes that have a block size larger than 4KB on the common x86 and x64 processors. (This limitation does not apply for the utilities of the e2fsprogs, for example, e2fsck or mke2fs. You can create and check volumes. The mke2fs utility reports a warning when you are creating a file system which the Linux Kernel isn't able to mount.)

The Ext2 file system driver of the Ext2 IFS software is able to access volumes which have a block size larger than the page size on Windows. The page size is on Windows:

The Ext2 file system driver works correctly on block sizes larger than the page size of Windows, but a performance penalty may arise when allocating new blocks while writing a file or directory. Since Ext2 is a file system with sparsing, a block for a file is allocated when an application writes any non-zero data bytes. If the block size is larger than the page size, the Ext2 driver has to do additional write operations on disk in order to zero out partial areas of any block. The Ext2 driver includes some optimization in order to avoid the performance penalty in some circumstances:

If you want to just access some file on an external hard disk drive, you can likely deal with the performance penalty. If you are using a fixed hard disk drive on your computer, you shouldn't use a volume which has a block size larger than the page size.

To conclude, the block size capabilities of the Ext2 file system driver only give a benefit if you are accessing volumes used with some uncommon hardware, for example, an Itanium box, or, not mentioned yet, a MIPS embedded computer, and others.

What files does the setup program install?

version description
ext2fs.sys
1.12 See note#1 File system driver (kernel mode) for the Ext2 file system.
ifsmount.sys
1.01 See note#1 IFS Mount Manager driver (kernel mode). Creates and deletes drive letters for any volume.
ifsdrives.dll
1.12 ActiveX control. Configures the IFS Mount Manager driver ifsmount.sys.
ifsdrives.cpl (all Windows versions prior Vista/Server 2008)
1.12 Control panel item "IFS Drives", which actually hosts the ActiveX control of ifsdrives.dll.
ifsdrives.exe (Windows Vista/Server 2008 or newer)
1.12 Control panel item "IFS Drives", which actually hosts the ActiveX control of ifsdrives.dll.

Note#1: There are thirteen separate versions of the drivers ext2fs.sys and ifsmount.sys for each of the supported Windows version and platforms. The setup application of this software package installs the correct drivers corresponding to the Windows version and platform used.

How do I uninstall the Ext2 IFS software?

Use the "Add/Remove Programs" item in the control panel to uninstall the "Ext2 IFS 1.12 for Windows" software.

Note: Uninstallation will require a reboot.

Valid XHTML 1.0! Valid CSS!