From Fedora Project Wiki

No edit summary
No edit summary
 
Line 20: Line 20:
<pre>
<pre>
[root] # mkfs.ext3 -E test_fs /dev/<device>
[root] # mkfs.ext3 -E test_fs /dev/<device>
</pre>
For newer e2fsprogs, they provide mkfs.ext4dev, so all you must do is:
<pre>
[root] # mkfs.ext4dev /dev/<device>
</pre>
</pre>


Line 25: Line 31:


<pre>
<pre>
[root] # tune2fs -E test_fs /dev/sda5</pre>
[root] # tune2fs -E test_fs /dev/sda5
</pre>


or for older e2fsprogs:
or for older e2fsprogs:
Line 33: Line 40:
debugfs 1.40.5 (27-Jan-2008)
debugfs 1.40.5 (27-Jan-2008)
debugfs:  set_super_value s_flags 4
debugfs:  set_super_value s_flags 4
debugfs:  quit</pre>
debugfs:  quit
</pre>


If you don't do this, you may get a message like this upon bootup:
If you don't do this, you may get a message like this upon bootup:

Latest revision as of 16:47, 25 September 2008

NOTE: ext4 is still in development. Please help test, but understand that things may go wrong, and you should not trust your only copy of important data to this filesystem until it's had more real-world exposure.

Rawhide and the F9 alpha can install onto an ext4dev filesystem root; first you need to tell (a.k.a. lie to) the installer with "iamanext4developer" (post-beta: just "ext4") on the boot commandline. This is akin to the "jfs" or "reiserfs" options for those filesystems.

Then you can do custom partitioning, and select ext4dev for any filesystem (except /boot - no grub support (yet)).

The install should proceed Just Fine(tm). If not, let me (EricSandeen) know.

See also the ext4 feature page .

And now for the caveats:

  • --(Due to bug 429857: Root inode of ext4dev root filesystem does not get selinux label, booting with selinux enabled & enforcing will fail. Boot with enforcing=0, and use restorecon on / to (hopefully) properly update the root inode's selinux attrs. I have a fix for this bug, so soon, kernel updates will resolve this. Please do test w/ selinux enabled though, as the new larger inodes and in-inode xattrs could use airtime.)-- Fixed.
  • There is no readily-available e2fsprogs which can repair your shiny new ext4dev filesystem. If something goes badly I'll help out because we need to know what went wrong, but so far there is no upstream e2fsprogs which can handle the new ext4 features. So please consider anything you put on ext4dev for now to be disposable, just to be on the safe side.
  • Greater-than 16T support is still not available; kernel code should handle it but there is no 64-bit capable mkfs at this point. If anyone can test above 8T though, that'd be nice! Large filesystem support will come after basic ext4/extents support is in place.
  • Recent (post-alpha) kernels have a new test in place before allowing a filesystem to be mounted with this development code - it requires a special flag to be set. This is both to prevent ext3 from accidentally being claimed as ext4, as well as to put a psychological barrier in place.  ;) When creating the filesystem, you must do:
[root] # mkfs.ext3 -E test_fs /dev/<device>

For newer e2fsprogs, they provide mkfs.ext4dev, so all you must do is:

[root] # mkfs.ext4dev /dev/<device>

for pre-existing filesystems, to set the flag, do:

[root] # tune2fs -E test_fs /dev/sda5

or for older e2fsprogs:

[root] # debugfs -w /dev/sda5
debugfs 1.40.5 (27-Jan-2008)
debugfs:  set_super_value s_flags 4
debugfs:  quit

If you don't do this, you may get a message like this upon bootup:

EXT4-fs: dm-1: not marked OK to use with test code
  • system-config-lvm does not yet know about ext4; bug 432065 is filed and contains a patch to Filesystem.py which should enable it (as well as for xfs). system-config-lvm (like anaconda) will require updating again for the ext4dev -> ext4 transition.