bug#13582: [PATCH] stat: add ext4 to the ext2/ext3 list

[Ondrej Vasik]

On Thu, 2013-01-31 at 09:02 +0100, Bernhard Voelker wrote:
> On 01/30/2013 11:44 PM, Bob Proulx wrote:
> > Bernhard Voelker wrote:
> >> b) just adding "ext4" to "ext2/ext3" as it has already been proposed
> >> by several people could break existing scripts that use code like this:
> >>
> >>>       test "$(stat -f -c %T .)" = ext2/ext3 && ...
> >>
> >> I'm wondering how often users check for the hard coded string
> >> "ext2/ext3"? Do we have any numbers?
> 
> > On the surface I don't think the proposed change is particularly
> > scary.
> > [...]
> >
> > As someone with a lot of years and lines of script writing behind me I
> > would always be very paranoid about operations such as "destroy_data"
> > based upon some string value like this.  I like to think that I
> > wouldn't be fooled into a data loss because of something like this.
> > [...]
> 
> That is about the same what I was thinking.
> When someone has written a script managing partitions and file systems,
> then I think he would (hopefully) never just use that well-cited
> snippet to guard existing data against destroying:
> 
>       case $(stat -f --format %T .) in
>         ext2/ext3) ;;
>         *) destroy_partition ;;
>       esac
> 
> First, it's running on Linux or another *NIX flavor, i.e. such
> a script would have to check for many other file system types, too.
> Is that reliable? Probably not.
> 
> Second, I think such a script would probably rely on other things
> rather than using coreutils' stat - e.g. letting the kernel decide
> by trying to "mount -r". Even 'file' knows how to distinguish
> between ext3 and ext4:
> 
>   $ file -s /dev/sdb3
>   /dev/sdb3: Linux rev 1.0 ext3 filesystem data, UUID=<...>, \
>   volume name "home" (needs journal recovery) (large files)
>   $ file -s /dev/sdb2
>   /dev/sdb2: Linux rev 1.0 ext4 filesystem data, UUID=<...>, \
>   volume name "rootfs" (extents) (large files) (huge files)

file uses identifiers for several features (journal, small/large
INCOMPAT and RO_INCOMPAT) to distinguish the ext2 family filesystems. It
should be possible to check for them, but I would expect several dozens
lines of code - which is probably too much for stat code. In addition -
if we go for this, should we change the well established ext2/ext3 to
exact filesystem type, if we recognize it?

> > However because the identifier is an ext2 identifier I would have
> > always reported it as ext2 regardless of whether ext3 or ext4 used it.
> > If there is no way to tell them apart then there is no way to tell.
> > Perhaps better to have reported the raw hex data value of it.
> > 
> > But that is all water under bridge now since the program was imported
> > with that "ext2/ext3" already emitted.  There is no difference in
> > identifier between those and the newer ext4.  I am inclined to say
> > that the identifier is "ext2" now even if ext5 uses it.  What if some
> > new xjzfs uses that same identifier?  It is the identifier that is
> > being reported and not the actual file system contents.  Therefore I
> > wouldn't change it unless the identifier itself is changed.
> 
> Right, stat is just reporting the human readable form of the
> magic number. If that number is used by different file system
> types, then stat should report all possibilities. It's the problem
> of those file systems to use different magic numbers (or not).
> I mean, the ext4 development team has deliberately chosen not to
> use a new number - they will have had their reasons.
> 
> With all that said, I'd +1 the patch.
> WDYT?

Personally, I don't like the ext2/ext3/ext4 approach - simply because it
is too long (and very common). This may break some layout in the scripts
(although I admit badly written). Even with this long form, it will be
not the longest identifier, "minix v2 (30 char.)" is longer, so some
potential overflows of some buffer are again just because of bad
scripts/programs. I don't think that anybody would use the "destroy
other than ext2/ext3 partitions approach" in the script - so this is
more artificial than real life example... still, there might be real
life complains about this longer form.

But even the best one approach - having code to reliably distinguish
between the types - so reporting just ext4 (or ext3) may break some
scripts. ext[234] as well and might be confusing. Same with "ext2
family"...
For me - no good option (even the ext2. ext3 vs. ext4 identification is
not perfect way, may break scripts relying on ext2/ext3 as well)... only
choosing lesser evil...

Greetings,
         Ondrej Vasik