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

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.

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.

Note

You need to
log in
before you can comment on or make changes to this bug.