Red Hat Bugzilla – Full Text Bug Listing
|Summary:||RFE: add ext4 to "stat -f" output|
|Product:||[Fedora] Fedora||Reporter:||Eric Sandeen <esandeen>|
|Component:||coreutils||Assignee:||Ondrej Vasik <ovasik>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||jdy, jim, kdudka, meyering, ovasik, twaugh|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-04-26 02:06:03 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Eric Sandeen 2009-02-13 15:13:14 EST
[root@inode ~]# mount | grep ext4 /dev/sda6 on / type ext4 (rw) [root@inode ~]# stat -f / File: "/" ID: 17feca01dbb6e35c Namelen: 255 Type: ext2/ext3 Block size: 4096 Fundamental block size: 4096 Blocks: Total: 1259071 Free: 416307 Available: 352349 Inodes: Total: 320000 Free: 175279 I suppose it would be nice to add ext4 to the list of possibilities :) (I don't know if it's worth digging further and actually reporting the correct ext$X....) Thanks, -Eric
Comment 1 Ondrej Vasik 2009-02-16 07:00:09 EST
I agree it would be nice, but stat is using statvfs (2) for that case - and statvfs uses the same magic number #0xEF53 for EXT2_SUPER_MAGIC , EXT3_SUPER_MAGIC and EXT4_SUPER_MAGIC - so no chance to recognize ext4 from it. It would mean to use something different for recognizing filesystem - and that thing has to be very portable to be accepted by coreutils upstream. Any idea?
Comment 2 Eric Sandeen 2009-02-16 10:37:46 EST
I would not worry about the further identification; it's ext's fault that they have 3 filesystems with the same magic number. :) I don't know of a good portable way without opencoding some ext* feature detection, and that would probably not be acceptable. If we could just add "/ext4" to the output, it'd be fine I think. Thanks, -Eric
Comment 3 Ondrej Vasik 2009-02-16 10:58:42 EST
Maybe Jim might know ... or at least he could change that directly in upstream git. Adding him to CC as ext4 is still not recognized in upstream git head...
Comment 4 Jim Meyering 2009-02-16 11:30:08 EST
Thanks. I've replied on the list: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/15831
Comment 5 Ondrej Vasik 2009-12-22 04:57:07 EST
Just want to add new recent upstream mailing list reference: http://lists.gnu.org/archive/html/bug-coreutils/2009-12/msg00221.html
Comment 6 Joel 2012-04-25 16:39:37 EDT
What is the progress on ext4 support for stat?
Comment 7 Eric Sandeen 2012-04-25 17:05:14 EDT
A big part of the problem is that "ext4" is a big, random collection of features. It's more a new driver codebase containing various & sundry new things, than a fixed on-disk format. You can turn any/all of the following on or off and mount it with the ext4 driver: * extents * delalloc * flex_bg * journaling * 64-bitness * "bigalloc" * .... etc .... So the question becomes, what exactly _is_ ext4? Best we can do is "ext2/3/4" or so, I think.
Comment 8 Ondrej Vasik 2012-04-25 19:33:20 EDT
But upstream (Jim Meyering) already rejected ext2/3/4 change - as it may break scripts - and recognizing ext4 based on some feature might be a tricky thing - as Eric mentioned - and will polute the stat code. Bad luck that ext2/3/4 uses the same magic for all filesystems.
Comment 9 Eric Sandeen 2012-04-25 20:08:06 EDT
Best to close it WONTFIX then, I guess?
Comment 10 Ondrej Vasik 2012-04-26 02:06:03 EDT
Probably... closing WONTFIX, anyone - feel free to reopen it if you find an easy way how to reliably distinguish ext2/3 and ext4 filesystem (or just propose it as reply in upstream thread mentioned in comment #4 or #5 - as this possible change has to be done/accepted upstream). These ways I'm aware of are too big for stat.c code.