Bug 485507
| 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> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | jdy, jim, kdudka, meyering, ovasik, twaugh |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-04-26 06:06:03 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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? 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. Thanks, -Eric 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... Thanks. I've replied on the list: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/15831 Just want to add new recent upstream mailing list reference: http://lists.gnu.org/archive/html/bug-coreutils/2009-12/msg00221.html What is the progress on ext4 support for stat? 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. 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. Best to close it WONTFIX then, I guess? 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. |
[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