Bug 485507

Summary: RFE: add ext4 to "stat -f" output
Product: [Fedora] Fedora Reporter: Eric Sandeen <esandeen>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: jdy, jim, kdudka, meyering, ovasik, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-26 02:06:03 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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....)

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[234]'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.

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:
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.