bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bob Proulx
Subject: bug#13582: [PATCH] stat: add ext4 to the ext2/ext3 list
Date: Wed, 30 Jan 2013 14:27:50 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

I am just adding references here to tie in the previous discussions.

The bugzilla.redhat.com discussion actually has the best analysis of
the problem.  However let me summarize (and plagarize) as best as I
can here.

In https://bugzilla.redhat.com/show_bug.cgi?id=485507

  Eric Sandeen proposed to add ext4 to the list of names
  currently reported for that type of file system ("ext2/ext3").

In response Jim stated:

  http://lists.gnu.org/archive/html/bug-coreutils/2009-02/msg00160.html

  I'm reluctant to change that string, because doing so might
  well break scripts that rely on them:

      case $(stat -f --format %T .) in
        ext2/ext3) ;;
        *) destroy_partition ;;
      esac

  Sure, script writers might well anticipate this and
  prefer to use the %t directive to get the type in hexadecimal,
  but that's far less readable.

  How much code (and how ugly) would be required to distinguish ext4
  from ext[23]?

This was further reinforced by Jim in a later discussion:

  http://lists.gnu.org/archive/html/bug-coreutils/2009-12/msg00229.html

  For the ext4-adding part, I'm a little reluctant,
  because it may break scripts that test via e.g.,

      test "$(stat -f -c %T .)" = ext2/ext3 && ...

  rather than the more portable -- in potential retrospect:

      case $(stat -f -c %T .) in
          ext2/ext3*) ... ;
      esac

In the previous thread Eric suggested some pseudo-code flow to
distinguish ext4 from ext* but it would have needed significant effort
to complete.  This was followed up in the in the bugzilla trail
especially this where we see that the problem of distinguishing ext4
is not trivial and opens a box of problems.  I think it is worthwhile
to share it here.

  https://bugzilla.redhat.com/show_bug.cgi?id=485507#c7
  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.

  https://bugzilla.redhat.com/show_bug.cgi?id=485507#c8
  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.

  https://bugzilla.redhat.com/show_bug.cgi?id=485507#c9
  Eric Sandeen 2012-04-25 20:08:06 EDT

  Best to close it WONTFIX then, I guess?

  https://bugzilla.redhat.com/show_bug.cgi?id=485507#c10
  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.

I think the above rationale is still a good place to start.  It is
unfortunate that ext4 is using the same identifier as ext3.  And the
same that ext3 used the same identifier as ext2.

Bob





reply via email to

[Prev in Thread] Current Thread [Next in Thread]