[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: call for brave ext4 testers in F9, with caveats

On Mon, Feb 4, 2008 at 9:23 AM, Eric Sandeen <sandeen redhat com> wrote:
> Hi Gang -
>  The ext4 filesystem is a feature slated for F9, and we (rh, ibm, bull,
>  clusterfs, and others) are working feverishly to get it ready for a
>  prime-time F9 fs option.
>  I'd like to get a bit more exposure if possible, so if you're feeling
>  like living on the cutting edge of filesystems, read on:
>  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" on the boot commandline.  This is akin to the "jfs"
>  or "reiserfs" options for those filesystems, but a higher hurdle (more
>  characters to type!).
>  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 know.
>  And now for the (known) caveats:
>  1) Due to bug 429857: Root inode of ext4dev root filesystem does not get
>  selinux label - booting with selinux enabled & enforcing will probably
>  fail.  Boot with enforcing=0, and use restorecon or chcon 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 and allow it
>  to be properly set (and retained).  Please do test w/ selinux enabled
>  though, as the new larger inodes and in-inode xattrs could use airtime.
>  2) 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 released
>  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.  extents-capable e2fsprogs should be available Real
>  Soon Now.
>  3) misc stuff - I've not yet tested ext4 over an encrypted block device,
>  or even over an lvm volume.  There may be some stack issues on x86 boxes
>  still, I'm working on slimming that down.  I hope that more real-world
>  use will shake out any remaining problems.
>  ... and I suppose I should put this into a wiki page:
>  http://fedoraproject.org/wiki/FedoraExt4
>  We can keep it updated with any further issues or resolutions.
>  Thanks!
>  -Eric
I "converted" my USB backup filesystem to ext4dev as described in this
thread, and then did my normal rsync.

FWIW, here are the messages from rsync and unmount:

Number of files: 349883
Number of files transferred: 103441
Total file size: 58603101927 bytes
Total transferred file size: 21723026327 bytes
Literal data: 21723032689 bytes
Matched data: 0 bytes
File list size: 8350613
File list generation time: 0.149 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 21738442241
Total bytes received: 2062982

sent 21738442241 bytes  received 2062982 bytes  4469216.82 bytes/sec
total size is 58603101927  speedup is 2.70

Feb  9 13:01:13 localhost kernel: EXT4-fs: mballoc: 18135 blocks 18135
reqs (0 success)
Feb  9 13:01:13 localhost kernel: EXT4-fs: mballoc: 18135 extents
scanned, 8932 goal hits, 9203 2^N hits, 0 breaks, 0 lost
Feb  9 13:01:13 localhost kernel: EXT4-fs: mballoc: 1161 generated and
it took 15700652
Feb  9 13:01:13 localhost kernel: EXT4-fs: mballoc: 5636543
preallocated, 305084 discarded

No perceived problems.

However, gnome-mount does not seem to automagically detect ext4dev
type file systems, and silently fails.

"gnome-mount --fstype ext4dev" does work, however.

Tom London

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]