[GIT PULL] Ext3 removal, quota & udf fixes

[GIT PULL] Ext3 removal, quota & udf fixes

[Jan Kara]

  Hello Linus,

  could you please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_linus

The biggest change in the pull is the removal of ext3 filesystem driver
(~28k lines removed).  Ext4 driver is a full featured replacement these
days and both RH and SUSE use it for several years without issues. Also
there are some workarounds in VM & block layer mainly for ext3 which we
could eventually get rid of. Other larger change is addition of proper
error handling for dquot_initialize().  The rest is small fixes and
cleanups.

Timing sucks for me for this merge window since I'm on vacation for these
two weeks without internet access. Hopefully things work out fine.

Top of the tree is 9181f8bf5abf. The full shortlog is:

Dan Carpenter (2):
      ext4: memory leak on error in ext4_symlink()
      quota: remove an unneeded condition

Dave Kleikamp (1):
      jfs: Handle error from dquot_initialize()

Jan Kara (10):
      quota: Propagate error from ->acquire_dquot()
      ext2: Handle error from dquot_initalize()
      ext4: Handle error from dquot_initialize()
      ocfs2: Handle error from dquot_initialize()
      reiserfs: Handle error from dquot_initialize()
      doc: Update doc about journalling layer
      fs: Remove ext3 filesystem driver
      block: Remove forced page bouncing under IO
      ext4: Improve ext4 Kconfig test
      udf: Don't modify filesystem for read-only mounts

Valentin Rothberg (1):
      mm/Kconfig: NEED_BOUNCE_POOL: clean-up condition

The diffstat is

 Documentation/DocBook/filesystems.tmpl |  178 +-
 Documentation/filesystems/ext2.txt     |    4 +-
 Documentation/filesystems/ext3.txt     |  209 +-
 Documentation/filesystems/vfs.txt      |    2 +-
 MAINTAINERS                            |   18 +-
 block/bounce.c                         |   31 +-
 fs/Kconfig                             |    5 +-
 fs/Makefile                            |    2 -
 fs/ext2/ialloc.c                       |    5 +-
 fs/ext2/inode.c                        |    7 +-
 fs/ext2/namei.c                        |   46 +-
 fs/ext3/Kconfig                        |   89 -
 fs/ext3/Makefile                       |   12 -
 fs/ext3/acl.c                          |  281 ---
 fs/ext3/acl.h                          |   72 -
 fs/ext3/balloc.c                       | 2158 -------------------
 fs/ext3/bitmap.c                       |   20 -
 fs/ext3/dir.c                          |  537 -----
 fs/ext3/ext3.h                         | 1332 ------------
 fs/ext3/ext3_jbd.c                     |   59 -
 fs/ext3/file.c                         |   79 -
 fs/ext3/fsync.c                        |  109 -
 fs/ext3/hash.c                         |  206 --
 fs/ext3/ialloc.c                       |  706 -------
 fs/ext3/inode.c                        | 3574 --------------------------------
 fs/ext3/ioctl.c                        |  327 ---
 fs/ext3/namei.c                        | 2586 -----------------------
 fs/ext3/namei.h                        |   27 -
 fs/ext3/resize.c                       | 1117 ----------
 fs/ext3/super.c                        | 3165 ----------------------------
 fs/ext3/symlink.c                      |   46 -
 fs/ext3/xattr.c                        | 1330 ------------
 fs/ext3/xattr.h                        |  136 --
 fs/ext3/xattr_security.c               |   78 -
 fs/ext3/xattr_trusted.c                |   54 -
 fs/ext3/xattr_user.c                   |   58 -
 fs/ext4/Kconfig                        |   54 +-
 fs/ext4/ialloc.c                       |    6 +-
 fs/ext4/inode.c                        |    7 +-
 fs/ext4/namei.c                        |   63 +-
 fs/ext4/super.c                        |   14 +-
 fs/jbd/Kconfig                         |   30 -
 fs/jbd/Makefile                        |    7 -
 fs/jbd/checkpoint.c                    |  782 -------
 fs/jbd/commit.c                        | 1021 ---------
 fs/jbd/journal.c                       | 2145 -------------------
 fs/jbd/recovery.c                      |  594 ------
 fs/jbd/revoke.c                        |  733 -------
 fs/jbd/transaction.c                   | 2237 --------------------
 fs/jfs/file.c                          |    7 +-
 fs/jfs/jfs_inode.c                     |    4 +-
 fs/jfs/namei.c                         |   54 +-
 fs/ocfs2/file.c                        |   22 +-
 fs/ocfs2/namei.c                       |   59 +-
 fs/ocfs2/quota_local.c                 |    4 +-
 fs/ocfs2/refcounttree.c                |    5 +-
 fs/quota/dquot.c                       |   88 +-
 fs/quota/quota.c                       |    4 +-
 fs/reiserfs/inode.c                    |    7 +-
 fs/reiserfs/namei.c                    |   63 +-
 fs/udf/super.c                         |    7 +-
 include/linux/blk_types.h              |    5 +-
 include/linux/jbd.h                    | 1047 ----------
 include/linux/jbd2.h                   |   41 +-
 include/linux/jbd_common.h             |   46 -
 include/linux/quotaops.h               |    5 +-
 include/trace/events/ext3.h            |  866 --------
 include/trace/events/jbd.h             |  194 --
 mm/Kconfig                             |    8 +-
 69 files changed, 505 insertions(+), 28389 deletions(-)
 delete mode 100644 fs/ext3/Kconfig
 delete mode 100644 fs/ext3/Makefile
 delete mode 100644 fs/ext3/acl.c
 delete mode 100644 fs/ext3/acl.h
 delete mode 100644 fs/ext3/balloc.c
 delete mode 100644 fs/ext3/bitmap.c
 delete mode 100644 fs/ext3/dir.c
 delete mode 100644 fs/ext3/ext3.h
 delete mode 100644 fs/ext3/ext3_jbd.c
 delete mode 100644 fs/ext3/file.c
 delete mode 100644 fs/ext3/fsync.c
 delete mode 100644 fs/ext3/hash.c
 delete mode 100644 fs/ext3/ialloc.c
 delete mode 100644 fs/ext3/inode.c
 delete mode 100644 fs/ext3/ioctl.c
 delete mode 100644 fs/ext3/namei.c
 delete mode 100644 fs/ext3/namei.h
 delete mode 100644 fs/ext3/resize.c
 delete mode 100644 fs/ext3/super.c
 delete mode 100644 fs/ext3/symlink.c
 delete mode 100644 fs/ext3/xattr.c
 delete mode 100644 fs/ext3/xattr.h
 delete mode 100644 fs/ext3/xattr_security.c
 delete mode 100644 fs/ext3/xattr_trusted.c
 delete mode 100644 fs/ext3/xattr_user.c
 delete mode 100644 fs/jbd/Kconfig
 delete mode 100644 fs/jbd/Makefile
 delete mode 100644 fs/jbd/checkpoint.c
 delete mode 100644 fs/jbd/commit.c
 delete mode 100644 fs/jbd/journal.c
 delete mode 100644 fs/jbd/recovery.c
 delete mode 100644 fs/jbd/revoke.c
 delete mode 100644 fs/jbd/transaction.c
 delete mode 100644 include/linux/jbd.h
 delete mode 100644 include/linux/jbd_common.h
 delete mode 100644 include/trace/events/ext3.h
 delete mode 100644 include/trace/events/jbd.h

							Thanks
								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Linus Torvalds]

On Sun, Aug 30, 2015 at 11:19 PM, Jan Kara <jack@suse.cz> wrote:
>
> The biggest change in the pull is the removal of ext3 filesystem driver
> (~28k lines removed).

I really am not ready to just remove ext3 without a lot of good
arguments. There might well be people who this use ext3 as ext3, and
don't want to update. I want more a rationale for removal than "ext4
can read old ext3 filesystems".

                  Linus

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Raymond Jennings]

On 08/31/15 14:37, Linus Torvalds wrote:
> On Sun, Aug 30, 2015 at 11:19 PM, Jan Kara <jack@suse.cz> wrote:
>> The biggest change in the pull is the removal of ext3 filesystem driver
>> (~28k lines removed).
> I really am not ready to just remove ext3 without a lot of good
> arguments. There might well be people who this use ext3 as ext3, and
> don't want to update. I want more a rationale for removal than "ext4
> can read old ext3 filesystems".
I actually would agree that having two drivers for the same filesystem 
is redundant and unneeded code duplication.

That said, I wouldn't mind myself if the ext4 driver were given a very 
grueling regression test to make sure it can actually handle old ext3 
systems as well as the ext3 driver can.  Just gutting an entire driver 
because another driver can handle it only makes sense if nothing can go 
wrong and the potential for causing regressions is quite obvious.

I think also that we should remove the ext2 driver before we remove the 
ext3 driver.

My two cents.
>                    Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Linus Torvalds]

On Mon, Aug 31, 2015 at 3:31 PM, Raymond Jennings <shentino@gmail.com> wrote:
>
> That said, I wouldn't mind myself if the ext4 driver were given a very
> grueling regression test to make sure it can actually handle old ext3
> systems as well as the ext3 driver can.

That's not my only worry. Things like "can you go back to ext3-only"
is an issue too - I don't think that's been a big priority for ext4
any more, and if there are any existing hold-outs that still use ext3,
they may want to be able to go back to old kernels.

So it's not just a "you can use ext4 instead" issue. Can you do that
*without* then forcing an upgrade forever on that partition? I'm not
sure the ext4 people are really even willing to guarantee that kind of
backwards compatibility.

I could be ok with removing ext3 in theory, but I haven't seen a lot
of rationale for it, and I don't know if there are still users who may
have their own good reasons to stay with ext3. Maybe there has been
lots of discussion about this on fsdevel (which I don't follow), and
I'm just lacking the background, but if so I want to see that
background. Not just a oneliner description that basically says
"remove ext3 support".

                    Linus

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Raymond Jennings]

On 08/31/15 15:39, Linus Torvalds wrote:
> On Mon, Aug 31, 2015 at 3:31 PM, Raymond Jennings <shentino@gmail.com> wrote:
>> That said, I wouldn't mind myself if the ext4 driver were given a very
>> grueling regression test to make sure it can actually handle old ext3
>> systems as well as the ext3 driver can.
> That's not my only worry. Things like "can you go back to ext3-only"
> is an issue too - I don't think that's been a big priority for ext4
> any more, and if there are any existing hold-outs that still use ext3,
> they may want to be able to go back to old kernels.
Then we should just consider anything making an ext3 system unusuable by 
older kernels as a regression to be stomped like any other.
> So it's not just a "you can use ext4 instead" issue. Can you do that
> *without* then forcing an upgrade forever on that partition? I'm not
> sure the ext4 people are really even willing to guarantee that kind of
> backwards compatibility.
Breaking that guarantee would be an example of such a regression.
> I could be ok with removing ext3 in theory, but I haven't seen a lot
> of rationale for it, and I don't know if there are still users who may
> have their own good reasons to stay with ext3. Maybe there has been
> lots of discussion about this on fsdevel (which I don't follow), and
> I'm just lacking the background, but if so I want to see that
> background. Not just a oneliner description that basically says
> "remove ext3 support".
I actually agree that removing support for ext3 as a filesystem is a bad 
idea.  That would be a regression.

What I'm in favor of is removing the ext3 code as redundant if ext4 code 
can handle everything.  Of course, for it to be truly redundant, the 
ext4 code has to actually be capable of managing an ext3 filesystem 
without bumping it out of compatibility with older ext3 kernels.  Any 
such bump would rightly be classified as a regression.
>                      Linus

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Theodore Ts'o]

On Mon, Aug 31, 2015 at 03:39:38PM -0700, Linus Torvalds wrote:
> 
> That's not my only worry. Things like "can you go back to ext3-only"
> is an issue too - I don't think that's been a big priority for ext4
> any more, and if there are any existing hold-outs that still use ext3,
> they may want to be able to go back to old kernels.

Yes, you can go back to ext3-only.  In fact, we do *not* automatically
upgrade the file system to use ext4-specific features.

> So it's not just a "you can use ext4 instead" issue. Can you do that
> *without* then forcing an upgrade forever on that partition? I'm not
> sure the ext4 people are really even willing to guarantee that kind of
> backwards compatibility.

Actually, we do guarantee this.  It's considered poor form to
automatically change the superblock to add new file system features in
a way that would break the ability for the user to roll back to an
older kernel.  This isn't just for ext3->ext4, but for new ext4
features such as metadata checksumming.  The user has to explicitly
enable the feature using "tune2fs -O new_feature /dev/sdXX".

A file system with ext3-only features is part of regression test
suites.  I also test an ext3 file system that has been converted to
ext4 using the tune2fs command, data=journal, nojournal, new
experimental features such as inline data, etc., etc.:

BEGIN TEST 4k: Ext4 4k block Mon Aug 24 23:01:09 EDT 2015
BEGIN TEST 1k: Ext4 1k block Mon Aug 24 23:47:13 EDT 2015
BEGIN TEST ext3: Ext4 4k block emulating ext3 Tue Aug 25 00:40:19 EDT 2015
BEGIN TEST nojournal: Ext4 4k block w/ no journal Tue Aug 25 01:23:16 EDT 2015
BEGIN TEST ext3conv: Ext4 4k block w/nodelalloc and no flex_bg Tue Aug 25 02:04:52 EDT 2015
BEGIN TEST dioread_nolock: Ext4 4k block w/dioread_nolock Tue Aug 25 02:48:32 EDT 2015
BEGIN TEST data_journal: Ext4 4k block w/data=journal Tue Aug 25 03:34:30 EDT 2015
BEGIN TEST inline: Ext4 4k block w/inline Tue Aug 25 04:36:47 EDT 2015
BEGIN TEST bigalloc: Ext4 4k block w/bigalloc Tue Aug 25 05:22:08 EDT 2015
BEGIN TEST bigalloc_1k: Ext4 1k block w/bigalloc Tue Aug 25 06:20:54 EDT 2015

I fire off the test suite using a single command: "gce-xfstests full"
which launches the regression test into the cloud (approximate cost
using Google Compute Engine: $1.50, at retail rates), and then 7-8
hours later, the results get e-mailed to me.  These tests get run
regularly during the development cycle, and I always do at least one
full test run before I send you each pull request.

So supporting and continuing to do regression testing for ext3 is
something we're doing today and I am willing to commit to continue to
do.

> I could be ok with removing ext3 in theory, but I haven't seen a lot
> of rationale for it, and I don't know if there are still users who may
> have their own good reasons to stay with ext3. Maybe there has been
> lots of discussion about this on fsdevel (which I don't follow), and
> I'm just lacking the background, but if so I want to see that
> background. Not just a oneliner description that basically says
> "remove ext3 support".

The main rationale is that two code bases is harder to support than
one.  When bugs get fixed in ext4, they don't necessarily get
back-propagated to ext3 except for a manual process where Jan notices
that a bug fixed in ext4 is also in ext3, and he manually ports the
patch over.

Both Red Hat and SuSE, as well as Debian and Ubuntu, are using ext4
with CONFIG_EXT4_USE_FOR_EXT23 for a couple of years now to support
ext2 and ext3 file systems.  So with the exception of some really
ancient enterprise Linux distros, and people who are manually
configuring their systems, very few people are likely using ext3 code
base, which means the chances that it bitrots increases.  Basically,
it's only been Jan's tireless work that has kept that from happening,
given that all of the major distro's have been using ext4 to support
ext2 and ext3 file systems.

Given that all of the major distributions are using ext4 to support
ext3, full backwards compatibility support for ext3 is something we
support today and will have to continue supporting regardless of
whether or not ext3 gets removed from the kernel sources.

Cheers,

						- Ted

P.S.  Even though most distributions are also using ext4 to support
ext2, I don't support removing ext2 at this time.  Like minix, it's a
simple file system that can be easily used by others to understand
what's needed to create a new file system.  

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Eric Sandeen]

On 8/31/15 5:39 PM, Linus Torvalds wrote:
> On Mon, Aug 31, 2015 at 3:31 PM, Raymond Jennings <shentino@gmail.com> wrote:
>>
>> That said, I wouldn't mind myself if the ext4 driver were given a very
>> grueling regression test to make sure it can actually handle old ext3
>> systems as well as the ext3 driver can.
> 
> That's not my only worry. Things like "can you go back to ext3-only"
> is an issue too - I don't think that's been a big priority for ext4
> any more, and if there are any existing hold-outs that still use ext3,
> they may want to be able to go back to old kernels.

Others have said it as well, but I'll restate: Yes, you can go "back."

But there's no real "going back" needed, because mounting an ext3
filesystem with ext4.ko hasn't "gone anywhere."  If you use ext4.ko,
you are running with a newer driver, but not a newer disk format.

> So it's not just a "you can use ext4 instead" issue. Can you do that
> *without* then forcing an upgrade forever on that partition? I'm not
> sure the ext4 people are really even willing to guarantee that kind of
> backwards compatibility.

Yeah, we are, I think I remember making an explicit stink about that quite
a while ago.  But I'm satisfied; we do use CONFIG_EXT4_USE_FOR_EXT23
in RHEL7, and we wouldn't do that if it might change disk format
behind our users' backs.

And it really is transparent; ext3 still shows up in /proc/filesystems,
and /proc/mounts still tells you you've mounted with ext3.

So yes, you can go back to 2.6.16 and mount it with the old ext3 driver,
if you like.

> I could be ok with removing ext3 in theory, but I haven't seen a lot
> of rationale for it, and I don't know if there are still users who may
> have their own good reasons to stay with ext3. Maybe there has been
> lots of discussion about this on fsdevel (which I don't follow), and
> I'm just lacking the background, but if so I want to see that
> background. Not just a oneliner description that basically says
> "remove ext3 support".

Yeah, the rationale is just about maintainability.  It makes little sense
to maintain a fairly large but separate codebase, when that old codebase
is just a subset of a newer, more actively maintained codebase.
And when most major distros have stopped using it, that old codebase
is going to do nothing but get crufty.

FWIW, this has been the plan all along, even though the timeline was just
a tad optimistic. [1] ;)

-Eric

[1] http://lwn.net/Articles/189950/

"At that point, perhaps 12-18 months out, we may request that the code in
fs/ext3/*.c be deleted and that fs/ext4 register itself as supporting the
ext3 filesystem as well."  -- tytso, June 2006 ;)

>                     Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/1/15 8:52 AM, Eric Sandeen wrote:
> On 8/31/15 5:39 PM, Linus Torvalds wrote:
>> On Mon, Aug 31, 2015 at 3:31 PM, Raymond Jennings
>> <shentino@gmail.com> wrote:
>>> 
>>> That said, I wouldn't mind myself if the ext4 driver were given
>>> a very grueling regression test to make sure it can actually
>>> handle old ext3 systems as well as the ext3 driver can.
>> 
>> That's not my only worry. Things like "can you go back to
>> ext3-only" is an issue too - I don't think that's been a big
>> priority for ext4 any more, and if there are any existing
>> hold-outs that still use ext3, they may want to be able to go
>> back to old kernels.
> 
> Others have said it as well, but I'll restate: Yes, you can go
> "back."
> 
> But there's no real "going back" needed, because mounting an ext3 
> filesystem with ext4.ko hasn't "gone anywhere."  If you use
> ext4.ko, you are running with a newer driver, but not a newer disk
> format.
> 
>> So it's not just a "you can use ext4 instead" issue. Can you do
>> that *without* then forcing an upgrade forever on that partition?
>> I'm not sure the ext4 people are really even willing to guarantee
>> that kind of backwards compatibility.
> 
> Yeah, we are, I think I remember making an explicit stink about
> that quite a while ago.  But I'm satisfied; we do use
> CONFIG_EXT4_USE_FOR_EXT23 in RHEL7, and we wouldn't do that if it
> might change disk format behind our users' backs.

As a "me too" datapoint, we do the same thing with SLE12.

- -Jeff

- -- 
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)

iQIcBAEBAgAGBQJV5cGbAAoJEB57S2MheeWy9z8QALz0EPV2V9MPzSTkQ/DyvcEK
V8GxQyHpOSwVLqU/J8f9+1vM7dbRR9bjXuN8YAZ/bmTf5GQA4opuCZK4KanK3xeo
JSQeFfO9O4gb3aiKdVxxXS3RhejR4WhQ+nQQ3HOIIXCjauU4vd88UH1tjcBR8PdE
DXKtq1KpqIWc5zLr22AgTRwkDiYauaziK2i6922DVl0rSOjfFw4BoV91pgE0pLgi
ojXKosmpST1VOlHKw7l2yOeMdVYUn1wJFgOprCXSLNwckszcqLgNbRYaOaiZmh7Z
c4zWdOkKQDI1/+THtNniF7xiDx2vFgtCSKbaU+hdsshxBHntLIIRj7vqOqfVLb85
m8lyshQDen8y7bahimCfr/hIGyXBuotl+jS4sryABInBf3AkuR3kI9gYJrb6YDWU
jt/0XnT4OIboB1G/Op+SLeNBBR+1RQn9iu559dw2JFQJFeT9JJOvbyaYU5Ijl8I4
eBxebee9laat3atbKVe4HTzGgNzbwCoA8KZuhtaDncR+jd6tsiSLsdlVKZw/P3g9
J35QNlOt6FyecDa9G3OYcpLsxffdv/fke2yT+R6LiN54oVY77OYRjFNY2X27yHWX
76qAOj+tkntfvFV5BjElT+uqXxqebb/kwLt2gUJJ68U/lVVYFHDJKjE2XXdf5omy
/N/PcMenBbsGq6H0UvzS
=G4VO
-----END PGP SIGNATURE-----

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Raymond Jennings]

On 08/31/15 15:31, Raymond Jennings wrote:
> On 08/31/15 14:37, Linus Torvalds wrote:
>> On Sun, Aug 30, 2015 at 11:19 PM, Jan Kara <jack@suse.cz> wrote:
>>> The biggest change in the pull is the removal of ext3 filesystem driver
>>> (~28k lines removed).
>> I really am not ready to just remove ext3 without a lot of good
>> arguments. There might well be people who this use ext3 as ext3, and
>> don't want to update. I want more a rationale for removal than "ext4
>> can read old ext3 filesystems".
> I actually would agree that having two drivers for the same filesystem 
> is redundant and unneeded code duplication.
>
> That said, I wouldn't mind myself if the ext4 driver were given a very 
> grueling regression test to make sure it can actually handle old ext3 
> systems as well as the ext3 driver can.  Just gutting an entire driver 
> because another driver can handle it only makes sense if nothing can 
> go wrong and the potential for causing regressions is quite obvious.
>
> I think also that we should remove the ext2 driver before we remove 
> the ext3 driver.
>
> My two cents.
Just to ask a general opinion:

Am I right that it's ok for kernel code to be organized how we (the 
developers) see fit as long as we don't break userspace or hardware in 
the process?

So long as we function properly, should userspace care about how our 
source code is structured?

I'm thinking yes, but it might be fruitful to see an answer archived on 
the list.
>>                    Linus
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Christoph Hellwig]

On Mon, Aug 31, 2015 at 03:31:58PM -0700, Raymond Jennings wrote:
> I think also that we should remove the ext2 driver before we remove the ext3
> driver.

Very strong disagreement here.  Compare to ext4 and ext3, ext2 is a very
different beast with a different architecture.  It's basically our
template for "simple" file system drivers, and very useful for that
alone, nevermind for all the systems that don't want a complicated
journaling or log based file system for various reasons.

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Albino B Neto]

2015-08-31 19:31 GMT-03:00 Raymond Jennings <shentino@gmail.com>:
> I think also that we should remove the ext2 driver before we remove the ext3
> driver.

Yes. It is logical to remove the old ext2 drive, because there are
more computers with ext3 that ext2. Ext2 is obsolete by existing
technologies.

-- 
Albino B Neto
www.bino.us
"Debian. Freedom to code. Code to freedom!" faw

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

On 2015-09-01 06:29, Albino B Neto wrote:
> 2015-08-31 19:31 GMT-03:00 Raymond Jennings <shentino@gmail.com>:
>> I think also that we should remove the ext2 driver before we remove the ext3
>> driver.
>
> Yes. It is logical to remove the old ext2 drive, because there are
> more computers with ext3 that ext2. Ext2 is obsolete by existing
> technologies.
>
NO, it is not logical.  A vast majority of Android smartphones in the 
wild use ext2, as do a very significant portion of embedded systems that 
don't have room for the few hundred kilobytes of extra code that the 
ext4 driver has in comparison to ext2.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Theodore Ts'o]

On Tue, Sep 01, 2015 at 03:39:45PM -0400, Austin S Hemmelgarn wrote:
> NO, it is not logical.  A vast majority of Android smartphones in the wild
> use ext2, as do a very significant portion of embedded systems that don't
> have room for the few hundred kilobytes of extra code that the ext4 driver
> has in comparison to ext2.

Citation, please?  Android switched to ext4 at the end of 2010.  It's
been five years, and most people have updated their phones in the last
3-5 years.

						- Ted

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

On 2015-09-01 19:58, Theodore Ts'o wrote:
> On Tue, Sep 01, 2015 at 03:39:45PM -0400, Austin S Hemmelgarn wrote:
>> NO, it is not logical.  A vast majority of Android smartphones in the wild
>> use ext2, as do a very significant portion of embedded systems that don't
>> have room for the few hundred kilobytes of extra code that the ext4 driver
>> has in comparison to ext2.
>
> Citation, please?  Android switched to ext4 at the end of 2010.  It's
> been five years, and most people have updated their phones in the last
> 3-5 years.
>
I was unaware that they had switched (I don't keep up on Android 
development), although the other part of my statement still holds.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Albino B Neto]

2015-08-31 23:53 GMT-03:00 Theodore Ts'o <tytso@mit.edu>:
> Yes, you can go back to ext3-only.  In fact, we do *not* automatically
> upgrade the file system to use ext4-specific features.
>
>> So it's not just a "you can use ext4 instead" issue. Can you do that
>> *without* then forcing an upgrade forever on that partition? I'm not
>> sure the ext4 people are really even willing to guarantee that kind of
>> backwards compatibility.
>
> Actually, we do guarantee this.  It's considered poor form to
> automatically change the superblock to add new file system features in
> a way that would break the ability for the user to roll back to an
> older kernel.  This isn't just for ext3->ext4, but for new ext4
> features such as metadata checksumming.  The user has to explicitly
> enable the feature using "tune2fs -O new_feature /dev/sdXX".

Yeah!

2015-09-01 16:39 GMT-03:00 Austin S Hemmelgarn <ahferroin7@gmail.com>:
> NO, it is not logical.  A vast majority of Android smartphones in the wild
> use ext2, as do a very significant portion of embedded systems that don't
> have room for the few hundred kilobytes of extra code that the ext4 driver
> has in comparison to ext2.

Ext2 portion embedded and Ext3 many machines.

-- 
Albino B Neto
www.bino.us
"Debian. Freedom to code. Code to freedom!" faw

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Raymond Jennings]

On 09/01/15 20:30, Albino B Neto wrote:
> 2015-08-31 23:53 GMT-03:00 Theodore Ts'o <tytso@mit.edu>:
>> Yes, you can go back to ext3-only.  In fact, we do *not* automatically
>> upgrade the file system to use ext4-specific features.
>>> So it's not just a "you can use ext4 instead" issue. Can you do that
>>> *without* then forcing an upgrade forever on that partition? I'm not
>>> sure the ext4 people are really even willing to guarantee that kind of
>>> backwards compatibility.
>> Actually, we do guarantee this.  It's considered poor form to
>> automatically change the superblock to add new file system features in
>> a way that would break the ability for the user to roll back to an
>> older kernel.  This isn't just for ext3->ext4, but for new ext4
>> features such as metadata checksumming.  The user has to explicitly
>> enable the feature using "tune2fs -O new_feature /dev/sdXX".
> Yeah!
>
> 2015-09-01 16:39 GMT-03:00 Austin S Hemmelgarn <ahferroin7@gmail.com>:
>> NO, it is not logical.  A vast majority of Android smartphones in the wild
>> use ext2, as do a very significant portion of embedded systems that don't
>> have room for the few hundred kilobytes of extra code that the ext4 driver
>> has in comparison to ext2.
> Ext2 portion embedded and Ext3 many machines.

So basically the game plan is gutting ext3 because code-dupe with ext4, 
but keep ext2 because ext4 is too big for embedded to outright replace ext2?

Hmm...are there any embedded systems out there that use ext3 and can fit 
its code ext3 but not ext4?
>

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

On 2015-09-02 01:46, Raymond Jennings wrote:
> On 09/01/15 20:30, Albino B Neto wrote:
>> 2015-08-31 23:53 GMT-03:00 Theodore Ts'o <tytso@mit.edu>:
>>> Yes, you can go back to ext3-only.  In fact, we do *not* automatically
>>> upgrade the file system to use ext4-specific features.
>>>> So it's not just a "you can use ext4 instead" issue. Can you do that
>>>> *without* then forcing an upgrade forever on that partition? I'm not
>>>> sure the ext4 people are really even willing to guarantee that kind of
>>>> backwards compatibility.
>>> Actually, we do guarantee this.  It's considered poor form to
>>> automatically change the superblock to add new file system features in
>>> a way that would break the ability for the user to roll back to an
>>> older kernel.  This isn't just for ext3->ext4, but for new ext4
>>> features such as metadata checksumming.  The user has to explicitly
>>> enable the feature using "tune2fs -O new_feature /dev/sdXX".
>> Yeah!
>>
>> 2015-09-01 16:39 GMT-03:00 Austin S Hemmelgarn <ahferroin7@gmail.com>:
>>> NO, it is not logical.  A vast majority of Android smartphones in the
>>> wild
>>> use ext2, as do a very significant portion of embedded systems that
>>> don't
>>> have room for the few hundred kilobytes of extra code that the ext4
>>> driver
>>> has in comparison to ext2.
>> Ext2 portion embedded and Ext3 many machines.
>
> So basically the game plan is gutting ext3 because code-dupe with ext4,
> but keep ext2 because ext4 is too big for embedded to outright replace
> ext2?
>
> Hmm...are there any embedded systems out there that use ext3 and can fit
> its code ext3 but not ext4?
Probably, but I don't know of any myself.  TBH, the systems that use 
ext2 because of space savings are usually ones with less than 64M of 
RAM, which is becoming a smaller and smaller market share.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Chuck Ebbert]

On Tue, 1 Sep 2015 15:39:45 -0400
Austin S Hemmelgarn <ahferroin7@gmail.com> wrote:

> On 2015-09-01 06:29, Albino B Neto wrote:
> > 2015-08-31 19:31 GMT-03:00 Raymond Jennings <shentino@gmail.com>:
> >> I think also that we should remove the ext2 driver before we remove the ext3
> >> driver.
> >
> > Yes. It is logical to remove the old ext2 drive, because there are
> > more computers with ext3 that ext2. Ext2 is obsolete by existing
> > technologies.
> >
> NO, it is not logical.  A vast majority of Android smartphones in the 
> wild use ext2, as do a very significant portion of embedded systems that 
> don't have room for the few hundred kilobytes of extra code that the 
> ext4 driver has in comparison to ext2.

Would it be possible to discard the code used for ext4 and ext3
features at module init time? So you could do something like:

  modprobe ext4 no_ext4 no_ext3

and all the space used by those functions would be freed and the
filesystem driver would mark all the ext3/ext4 features as
unsupported.

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

On 2015-09-02 07:58, Chuck Ebbert wrote:
> On Tue, 1 Sep 2015 15:39:45 -0400
> Austin S Hemmelgarn <ahferroin7@gmail.com> wrote:
>
>> On 2015-09-01 06:29, Albino B Neto wrote:
>>> 2015-08-31 19:31 GMT-03:00 Raymond Jennings <shentino@gmail.com>:
>>>> I think also that we should remove the ext2 driver before we remove the ext3
>>>> driver.
>>>
>>> Yes. It is logical to remove the old ext2 drive, because there are
>>> more computers with ext3 that ext2. Ext2 is obsolete by existing
>>> technologies.
>>>
>> NO, it is not logical.  A vast majority of Android smartphones in the
>> wild use ext2, as do a very significant portion of embedded systems that
>> don't have room for the few hundred kilobytes of extra code that the
>> ext4 driver has in comparison to ext2.
>
> Would it be possible to discard the code used for ext4 and ext3
> features at module init time? So you could do something like:
>
>    modprobe ext4 no_ext4 no_ext3
>
> and all the space used by those functions would be freed and the
> filesystem driver would mark all the ext3/ext4 features as
> unsupported.
>
Personally, I think this is a great idea.  It would allow people who 
need the low memory usage to transition over to the ext4 driver while 
keeping the memory usage low.  In such a case, I would almost suggest 
making an alias for the ext4 module (extfs maybe?) as modprobe ext4 
no_ext4 has the potential to significantly confuse people.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Andreas Dilger]

On Aug 31, 2015, at 3:37 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> On Sun, Aug 30, 2015 at 11:19 PM, Jan Kara <jack@suse.cz> wrote:
>> 
>> The biggest change in the pull is the removal of ext3 filesystem driver
>> (~28k lines removed).
> 
> I really am not ready to just remove ext3 without a lot of good
> arguments. There might well be people who this use ext3 as ext3, and
> don't want to update. I want more a rationale for removal than "ext4
> can read old ext3 filesystems".

The ext4 code can read and write ext3 filesystems without any
compatibility issues (i.e. none of the ext4-specific features are
enabled automatically) and have been doing so for all RHEL and SLES
users for the past several years via the CONFIG_EXT4_USE_FOR_EXT23
option (added in commit 24b58424 in 2009).  It looks like the same
for Ubuntu since early 2014 also.

The ext4-specific features either need to be enabled specifically
via tune2fs (if possible) or at mkfs time.

Cheers, Andreas

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Mel Gorman]

On Mon, Aug 31, 2015 at 02:37:38PM -0700, Linus Torvalds wrote:
> On Sun, Aug 30, 2015 at 11:19 PM, Jan Kara <jack@suse.cz> wrote:
> >
> > The biggest change in the pull is the removal of ext3 filesystem driver
> > (~28k lines removed).
> 
> I really am not ready to just remove ext3 without a lot of good
> arguments. There might well be people who this use ext3 as ext3, and
> don't want to update. I want more a rationale for removal than "ext4
> can read old ext3 filesystems".
> 

This is not my area at all but as Jan said he was out on vacation and
offline so there is no chance for him to adjust the tree before the window
closes. I'm going going to try and guess what justifications he might have
used if he was online.

1. Backwards compatibility -- other knowledgeable people, particularly
   Ted, already pointed out that backwards compatibility is guaranteed.
   I know SLE is using the ext4 driver for ext3 filesystems and AFAIK,
   there has been no bugs related to distro upgrades that failed to mount
   an ext3 filesystem with the ext4 driver. As other distributions made
   a similar decision and there is a lack of bug reports, there is some
   evidence that the guarantee is adhered to


2. ext4 driver performance -- when SLE considered switching to the ext4
   driver, I successfully checked that the ext4 driver matched or exceeded
   the performance of the ext3 driver. Granted, this was limited in terms
   of types of storage but as other distros are also using ext4 driver,
   I'm guessing that no one found regressions. I don't have the data any
   more but I don't recall a single instance where the ext3 driver was better

2. ext3-specific hack removals in block and VM. The merge request stated
   that some workarounds in the VM and block layer could be got rid of but
   I don't have a comprehensive list. Glancing at the branch though, at
   least one hack is removed with "block: Remove forced page bouncing under
   IO". I did not investigate deeply but it looks like cancel_dirty_page
   is another potential candidate for going away.

3. Missing fixes. Fixes applied to ext4 have to be manually back-ported
   to ext3, mostly by Jan, but it's possible one will be missed and ext3
   slowly bit rots. Ted already said this a lot better than I did so I'll
   just repeat it

	Both Red Hat and SuSE, as well as Debian and Ubuntu, are using
	ext4 with CONFIG_EXT4_USE_FOR_EXT23 for a couple of years now
	to support ext2 and ext3 file systems.	So with the exception of
	some really ancient enterprise Linux distros, and people who are
	manually configuring their systems, very few people are likely using
	ext3 code base, which means the chances that it bitrots increases.
	Basically, it's only been Jan's tireless work that has kept that
	from happening, given that all of the major distro's have been
	using ext4 to support ext2 and ext3 file systems.

On the flip side, there does not appear to be any good reason for
keeping the ext3 driver around because if there ever is a case where an
old kernel is required to mount an ext3 filesystem then it appears the
ext4 developers would consider it a bug.

-- 
Mel Gorman
SUSE Labs

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Darrick J. Wong]

On Wed, Sep 02, 2015 at 05:52:01PM +0100, Mel Gorman wrote:
> On Mon, Aug 31, 2015 at 02:37:38PM -0700, Linus Torvalds wrote:
> > On Sun, Aug 30, 2015 at 11:19 PM, Jan Kara <jack@suse.cz> wrote:
> > >
> > > The biggest change in the pull is the removal of ext3 filesystem driver
> > > (~28k lines removed).
> > 
> > I really am not ready to just remove ext3 without a lot of good
> > arguments. There might well be people who this use ext3 as ext3, and
> > don't want to update. I want more a rationale for removal than "ext4
> > can read old ext3 filesystems".
> > 
> 
> This is not my area at all but as Jan said he was out on vacation and
> offline so there is no chance for him to adjust the tree before the window
> closes. I'm going going to try and guess what justifications he might have
> used if he was online.
> 
> 1. Backwards compatibility -- other knowledgeable people, particularly
>    Ted, already pointed out that backwards compatibility is guaranteed.
>    I know SLE is using the ext4 driver for ext3 filesystems and AFAIK,
>    there has been no bugs related to distro upgrades that failed to mount
>    an ext3 filesystem with the ext4 driver. As other distributions made
>    a similar decision and there is a lack of bug reports, there is some
>    evidence that the guarantee is adhered to
> 
> 
> 2. ext4 driver performance -- when SLE considered switching to the ext4
>    driver, I successfully checked that the ext4 driver matched or exceeded
>    the performance of the ext3 driver. Granted, this was limited in terms
>    of types of storage but as other distros are also using ext4 driver,
>    I'm guessing that no one found regressions. I don't have the data any
>    more but I don't recall a single instance where the ext3 driver was better
> 
> 2. ext3-specific hack removals in block and VM. The merge request stated
>    that some workarounds in the VM and block layer could be got rid of but
>    I don't have a comprehensive list. Glancing at the branch though, at
>    least one hack is removed with "block: Remove forced page bouncing under

I would be happy if the fs bounce buffering band-aid went away forever. :)

>    IO". I did not investigate deeply but it looks like cancel_dirty_page
>    is another potential candidate for going away.
> 
> 3. Missing fixes. Fixes applied to ext4 have to be manually back-ported
>    to ext3, mostly by Jan, but it's possible one will be missed and ext3
>    slowly bit rots. Ted already said this a lot better than I did so I'll
>    just repeat it
> 
> 	Both Red Hat and SuSE, as well as Debian and Ubuntu, are using
> 	ext4 with CONFIG_EXT4_USE_FOR_EXT23 for a couple of years now
> 	to support ext2 and ext3 file systems.	So with the exception of
> 	some really ancient enterprise Linux distros, and people who are
> 	manually configuring their systems, very few people are likely using
> 	ext3 code base, which means the chances that it bitrots increases.
> 	Basically, it's only been Jan's tireless work that has kept that
> 	from happening, given that all of the major distro's have been
> 	using ext4 to support ext2 and ext3 file systems.
> 
> On the flip side, there does not appear to be any good reason for
> keeping the ext3 driver around because if there ever is a case where an
> old kernel is required to mount an ext3 filesystem then it appears the
> ext4 developers would consider it a bug.

Yes, that would be a bug.

--D

> 
> -- 
> Mel Gorman
> SUSE Labs
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Linus Torvalds]

On Wed, Sep 2, 2015 at 11:45 AM, Darrick J. Wong
<darrick.wong@oracle.com> wrote:
> On Wed, Sep 02, 2015 at 05:52:01PM +0100, Mel Gorman wrote:
>> On the flip side, there does not appear to be any good reason for
>> keeping the ext3 driver around because if there ever is a case where an
>> old kernel is required to mount an ext3 filesystem then it appears the
>> ext4 developers would consider it a bug.
>
> Yes, that would be a bug.

So the thing I'm happy to see is that the ext4 developers seem to
unanimously agree that maintaining ext3 compatibility is part of their
job, and nobody seems to be arguing for keeping ext3 around. As long
as any possible regressions from ext3 removal have a clear "yup, it's
on us" from the ext4 people,  I don't mind removing it. I was
expecting ext4 people to not be thrilled about supporting possible
legacy cases.

As a result, I'm personally convinced. I'll get around to the
filesystem pulls tomorrow unless something unexpected happens, and
expect to pull Jan's ext3-removal tree unless somebody suddenly speaks
up.

Thanks,

               Linus

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Albino B Neto]

2015-09-02 20:47 GMT-03:00 Linus Torvalds <torvalds@linux-foundation.org>:
> On Wed, Sep 2, 2015 at 11:45 AM, Darrick J. Wong
> <darrick.wong@oracle.com> wrote:
>> Yes, that would be a bug.
>
> So the thing I'm happy to see is that the ext4 developers seem to
> unanimously agree that maintaining ext3 compatibility is part of their
> job, and nobody seems to be arguing for keeping ext3 around. As long
> as any possible regressions from ext3 removal have a clear "yup, it's
> on us" from the ext4 people,  I don't mind removing it. I was
> expecting ext4 people to not be thrilled about supporting possible
> legacy cases.

Good.

The future of ext4 ? Are you (developers) write other file system ?

-- 
Albino B Neto
www.bino.us
"Debian. Freedom to code. Code to freedom!" faw

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Darrick J. Wong]

On Thu, Sep 03, 2015 at 08:28:38AM -0300, Albino B Neto wrote:
> 2015-09-02 20:47 GMT-03:00 Linus Torvalds <torvalds@linux-foundation.org>:
> > On Wed, Sep 2, 2015 at 11:45 AM, Darrick J. Wong
> > <darrick.wong@oracle.com> wrote:
> >> Yes, that would be a bug.
> >
> > So the thing I'm happy to see is that the ext4 developers seem to
> > unanimously agree that maintaining ext3 compatibility is part of their
> > job, and nobody seems to be arguing for keeping ext3 around. As long
> > as any possible regressions from ext3 removal have a clear "yup, it's
> > on us" from the ext4 people,  I don't mind removing it. I was
> > expecting ext4 people to not be thrilled about supporting possible
> > legacy cases.
> 
> Good.
> 
> The future of ext4 ? Are you (developers) write other file system ?

Well I was working on a new one called EXT3000 with all new servos, but then I
had to reuse the start and stop controls for something else and now the whole
thing is SOL.  I guess I'll go watch a movie instead.

;)

--D

> 
> -- 
> Albino B Neto
> www.bino.us
> "Debian. Freedom to code. Code to freedom!" faw
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Jan Kara]

On Wed 02-09-15 16:47:24, Linus Torvalds wrote:
> On Wed, Sep 2, 2015 at 11:45 AM, Darrick J. Wong
> <darrick.wong@oracle.com> wrote:
> > On Wed, Sep 02, 2015 at 05:52:01PM +0100, Mel Gorman wrote:
> >> On the flip side, there does not appear to be any good reason for
> >> keeping the ext3 driver around because if there ever is a case where an
> >> old kernel is required to mount an ext3 filesystem then it appears the
> >> ext4 developers would consider it a bug.
> >
> > Yes, that would be a bug.
> 
> So the thing I'm happy to see is that the ext4 developers seem to
> unanimously agree that maintaining ext3 compatibility is part of their
> job, and nobody seems to be arguing for keeping ext3 around. As long
> as any possible regressions from ext3 removal have a clear "yup, it's
> on us" from the ext4 people,  I don't mind removing it. I was
> expecting ext4 people to not be thrilled about supporting possible
> legacy cases.
> 
> As a result, I'm personally convinced. I'll get around to the
> filesystem pulls tomorrow unless something unexpected happens, and
> expect to pull Jan's ext3-removal tree unless somebody suddenly speaks
> up.

Thanks for pulling. Next time I will do a better job when writing a
changelog for such large change. We were discussing this on and off for
last two years with other ext4 developers so when I finally decided the
time for removal has come, it felt obvious to me...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Richard Yao]

What happens with this patch if /dev/$DEVICE is ext4 formatted and someone runs
`mount -t ext3 /dev/$DEVICE $MNT`?

This should fail with the ext3 driver, but it looks like it will work fine with
CONFIG_EXT4_USE_FOR_EXT23 because ext3_fs_type maps to ext4_mount. My system is
not built with CONFIG_EXT4_USE_FOR_EXT23 (long story short: it uses a RHEL6
derived config on Linux 4.1) and I do not have time to rebuild it to verify my
suspicion, but I imagine there are others on the list that could trivially check
this.

Also, new kernels are typically drop-in replacements on older userlands. An edge
case that no one appears to have mentioned is the possibility of using a newer
kernel on an older system where the initramfs generator might only include ext3,
which this would break. It might not be terrible to write a small dummy ext3
module whose only purpose is to depend on ext4 and load it into the kernel on
those systems. That way initramfs software that properly grabs module
dependencies will include the ext4 module and `modprobe ext3` will do what it
always did in terms of making ext3 file systems mountable. I suppose that we
could use aliases, but given that there is a compatibility shim for CONFIG_EXT3
to avoid surprises, a dummy module seems reasonable.

These are the only two things that I see preventing ext4 from being a drop-in
replacement for ext3.

That said, my only connection with ext3/ext4 is that I am one of the genkernel
developers (Gentoo's  Linux initramfs/kernel genreation framework/scripts), so
my opinion might not matter much here, but I am also in favor of killing ext3 in
favor of CONFIG_EXT4_USE_FOR_EXT23.

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Eric Sandeen]

On 9/3/15 1:22 PM, Richard Yao wrote:
> What happens with this patch if /dev/$DEVICE is ext4 formatted and someone runs
> `mount -t ext3 /dev/$DEVICE $MNT`?
> 
> This should fail with the ext3 driver, but it looks like it will work fine with
> CONFIG_EXT4_USE_FOR_EXT23 because ext3_fs_type maps to ext4_mount.

Did you test it?

# truncate --size=1g fsfile
# mkfs.ext4 fsfile
# mount -o loop -t ext3 fsfile
mount: wrong fs type, <snip>
# dmesg | tail
# EXT4-fs: (loop0): couldn't mount as ext3 due to feature incompatibilities

> My system is
> not built with CONFIG_EXT4_USE_FOR_EXT23 (long story short: it uses a RHEL6
> derived config on Linux 4.1) and I do not have time to rebuild it to verify my
> suspicion, but I imagine there are others on the list that could trivially check
> this.

Well by all means, let me do that for you.  :)

> Also, new kernels are typically drop-in replacements on older userlands. An edge
> case that no one appears to have mentioned is the possibility of using a newer
> kernel on an older system where the initramfs generator might only include ext3,
> which this would break. It might not be terrible to write a small dummy ext3
> module whose only purpose is to depend on ext4 and load it into the kernel on
> those systems. That way initramfs software that properly grabs module
> dependencies will include the ext4 module and `modprobe ext3` will do what it
> always did in terms of making ext3 file systems mountable. I suppose that we
> could use aliases, but given that there is a compatibility shim for CONFIG_EXT3
> to avoid surprises, a dummy module seems reasonable.

I'm not wise in the ways of initramfs generation, so I'll defer on this one.

-Eric

> These are the only two things that I see preventing ext4 from being a drop-in
> replacement for ext3.
> 
> That said, my only connection with ext3/ext4 is that I am one of the genkernel
> developers (Gentoo's  Linux initramfs/kernel genreation framework/scripts), so
> my opinion might not matter much here, but I am also in favor of killing ext3 in
> favor of CONFIG_EXT4_USE_FOR_EXT23.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Richard Yao]

On Thu, Sep 03, 2015 at 01:36:45PM -0500, Eric Sandeen wrote:
> On 9/3/15 1:22 PM, Richard Yao wrote:
> > What happens with this patch if /dev/$DEVICE is ext4 formatted and someone runs
> > `mount -t ext3 /dev/$DEVICE $MNT`?
> > 
> > This should fail with the ext3 driver, but it looks like it will work fine with
> > CONFIG_EXT4_USE_FOR_EXT23 because ext3_fs_type maps to ext4_mount.
> 
> Did you test it?
> 
> # truncate --size=1g fsfile
> # mkfs.ext4 fsfile
> # mount -o loop -t ext3 fsfile
> mount: wrong fs type, <snip>
> # dmesg | tail
> # EXT4-fs: (loop0): couldn't mount as ext3 due to feature incompatibilities
> 
> > My system is
> > not built with CONFIG_EXT4_USE_FOR_EXT23 (long story short: it uses a RHEL6
> > derived config on Linux 4.1) and I do not have time to rebuild it to verify my
> > suspicion, but I imagine there are others on the list that could trivially check
> > this.
> 
> Well by all means, let me do that for you.  :)

I had vaguely recalled that working, but I am glad to see that my recollection
is wrong. Thanks for confirming it.

> > Also, new kernels are typically drop-in replacements on older userlands. An edge
> > case that no one appears to have mentioned is the possibility of using a newer
> > kernel on an older system where the initramfs generator might only include ext3,
> > which this would break. It might not be terrible to write a small dummy ext3
> > module whose only purpose is to depend on ext4 and load it into the kernel on
> > those systems. That way initramfs software that properly grabs module
> > dependencies will include the ext4 module and `modprobe ext3` will do what it
> > always did in terms of making ext3 file systems mountable. I suppose that we
> > could use aliases, but given that there is a compatibility shim for CONFIG_EXT3
> > to avoid surprises, a dummy module seems reasonable.
> 
> I'm not wise in the ways of initramfs generation, so I'll defer on this one.
> 
> -Eric
> 
> > These are the only two things that I see preventing ext4 from being a drop-in
> > replacement for ext3.
> > 
> > That said, my only connection with ext3/ext4 is that I am one of the genkernel
> > developers (Gentoo's  Linux initramfs/kernel genreation framework/scripts), so
> > my opinion might not matter much here, but I am also in favor of killing ext3 in
> > favor of CONFIG_EXT4_USE_FOR_EXT23.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Darrick J. Wong]

On Thu, Sep 03, 2015 at 06:22:25PM +0000, Richard Yao wrote:
> What happens with this patch if /dev/$DEVICE is ext4 formatted and someone runs
> `mount -t ext3 /dev/$DEVICE $MNT`?
> 
> This should fail with the ext3 driver, but it looks like it will work fine with
> CONFIG_EXT4_USE_FOR_EXT23 because ext3_fs_type maps to ext4_mount. My system is
> not built with CONFIG_EXT4_USE_FOR_EXT23 (long story short: it uses a RHEL6
> derived config on Linux 4.1) and I do not have time to rebuild it to verify my
> suspicion, but I imagine there are others on the list that could trivially check
> this.

On 4.2 with CONFIG_EXT4_USE_FOR_EXT23:

# mke2fs -T ext4 /dev/sda
# mount /dev/sda /mnt -t ext3
mount: wrong fs type, bad option, bad superblock on /dev/sda,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

# lsmod|grep ext 
ext4                  630784  0 
jbd2                  126976  1 ext4
mbcache                20480  1 ext4
# dmesg
<snip>
[74559.632979] EXT4-fs (sda): couldn't mount as ext3 due to feature incompatibilities

> Also, new kernels are typically drop-in replacements on older userlands. An edge
> case that no one appears to have mentioned is the possibility of using a newer
> kernel on an older system where the initramfs generator might only include ext3,
> which this would break. It might not be terrible to write a small dummy ext3
> module whose only purpose is to depend on ext4 and load it into the kernel on
> those systems. That way initramfs software that properly grabs module
> dependencies will include the ext4 module and `modprobe ext3` will do what it

Well, if it goes looking for ext3.ko directly it will fail, but...

# modinfo ext3
filename:       /lib/modules/4.2.0-mcsum/kernel/fs/ext4/ext4.ko
license:        GPL
description:    Fourth Extended Filesystem
author:         Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
alias:          fs-ext4
alias:          ext3
alias:          fs-ext3
<snip>

I don't know about RHEL initrd scripts, but Ubuntu's use some modprobe trickery
which ensures that it picks up the correct ext4.ko.  It does something similar
to this:

# modprobe --ignore-install --quiet --show-depends ext3 | sed -e 's/^insmod //g'
/lib/modules/4.2.0-mcsum/kernel/fs/mbcache.ko 
/lib/modules/4.2.0-mcsum/kernel/fs/jbd2/jbd2.ko 
/lib/modules/4.2.0-mcsum/kernel/fs/ext4/ext4.ko

to pick up the modules for the initramfs.  Not sure what the other distros
do, though.

> always did in terms of making ext3 file systems mountable. I suppose that we
> could use aliases, but given that there is a compatibility shim for CONFIG_EXT3
> to avoid surprises, a dummy module seems reasonable.
> 
> These are the only two things that I see preventing ext4 from being a drop-in
> replacement for ext3.
> 
> That said, my only connection with ext3/ext4 is that I am one of the genkernel
> developers (Gentoo's  Linux initramfs/kernel genreation framework/scripts), so
> my opinion might not matter much here, but I am also in favor of killing ext3 in
> favor of CONFIG_EXT4_USE_FOR_EXT23.

:)

--D

> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Richard Yao]

On Thu, Sep 03, 2015 at 11:36:57AM -0700, Darrick J. Wong wrote:
> On Thu, Sep 03, 2015 at 06:22:25PM +0000, Richard Yao wrote:
> > What happens with this patch if /dev/$DEVICE is ext4 formatted and someone runs
> > `mount -t ext3 /dev/$DEVICE $MNT`?
> > 
> > This should fail with the ext3 driver, but it looks like it will work fine with
> > CONFIG_EXT4_USE_FOR_EXT23 because ext3_fs_type maps to ext4_mount. My system is
> > not built with CONFIG_EXT4_USE_FOR_EXT23 (long story short: it uses a RHEL6
> > derived config on Linux 4.1) and I do not have time to rebuild it to verify my
> > suspicion, but I imagine there are others on the list that could trivially check
> > this.
> 
> On 4.2 with CONFIG_EXT4_USE_FOR_EXT23:
> 
> # mke2fs -T ext4 /dev/sda
> # mount /dev/sda /mnt -t ext3
> mount: wrong fs type, bad option, bad superblock on /dev/sda,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so
> 
> # lsmod|grep ext 
> ext4                  630784  0 
> jbd2                  126976  1 ext4
> mbcache                20480  1 ext4
> # dmesg
> <snip>
> [74559.632979] EXT4-fs (sda): couldn't mount as ext3 due to feature incompatibilities
> 
> > Also, new kernels are typically drop-in replacements on older userlands. An edge
> > case that no one appears to have mentioned is the possibility of using a newer
> > kernel on an older system where the initramfs generator might only include ext3,
> > which this would break. It might not be terrible to write a small dummy ext3
> > module whose only purpose is to depend on ext4 and load it into the kernel on
> > those systems. That way initramfs software that properly grabs module
> > dependencies will include the ext4 module and `modprobe ext3` will do what it
> 
> Well, if it goes looking for ext3.ko directly it will fail, but...
> 
> # modinfo ext3
> filename:       /lib/modules/4.2.0-mcsum/kernel/fs/ext4/ext4.ko
> license:        GPL
> description:    Fourth Extended Filesystem
> author:         Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
> alias:          fs-ext4
> alias:          ext3
> alias:          fs-ext3
> <snip>
> 
> I don't know about RHEL initrd scripts, but Ubuntu's use some modprobe trickery
> which ensures that it picks up the correct ext4.ko.  It does something similar
> to this:
> 
> # modprobe --ignore-install --quiet --show-depends ext3 | sed -e 's/^insmod //g'
> /lib/modules/4.2.0-mcsum/kernel/fs/mbcache.ko 
> /lib/modules/4.2.0-mcsum/kernel/fs/jbd2/jbd2.ko 
> /lib/modules/4.2.0-mcsum/kernel/fs/ext4/ext4.ko
> 
> to pick up the modules for the initramfs.  Not sure what the other distros
> do, though.

Unfortunately, the genkernel team was not aware of this when it wrote support
for including kernel modules and I suspect others writing initramfs archive
generators did not either.

https://gitweb.gentoo.org/proj/genkernel.git/tree/gen_initramfs.sh#n638
https://gitweb.gentoo.org/proj/genkernel.git/tree/gen_moddeps.sh
https://gitweb.gentoo.org/proj/genkernel.git/tree/defaults/modules_load

The way that works is that the module names are specified in a MODULES_*
variable and then we search for dependencies based on what is specified in
modules.dep. If you have an old enough version of the initramfs genreator, ext4
is not specified and it will not recognize the alias.

I admit that this is likely a very rare edge case. I do not feel too strongly
about breaking the older initramfs software. I just wanted to make sure others
knew that they were.

> > always did in terms of making ext3 file systems mountable. I suppose that we
> > could use aliases, but given that there is a compatibility shim for CONFIG_EXT3
> > to avoid surprises, a dummy module seems reasonable.
> > 
> > These are the only two things that I see preventing ext4 from being a drop-in
> > replacement for ext3.
> > 
> > That said, my only connection with ext3/ext4 is that I am one of the genkernel
> > developers (Gentoo's  Linux initramfs/kernel genreation framework/scripts), so
> > my opinion might not matter much here, but I am also in favor of killing ext3 in
> > favor of CONFIG_EXT4_USE_FOR_EXT23.
> 
> :)
> 
> --D
> 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Darrick J. Wong]

On Thu, Sep 03, 2015 at 07:16:19PM +0000, Richard Yao wrote:
> On Thu, Sep 03, 2015 at 11:36:57AM -0700, Darrick J. Wong wrote:
> > On Thu, Sep 03, 2015 at 06:22:25PM +0000, Richard Yao wrote:
> > > What happens with this patch if /dev/$DEVICE is ext4 formatted and someone runs
> > > `mount -t ext3 /dev/$DEVICE $MNT`?
> > > 
> > > This should fail with the ext3 driver, but it looks like it will work fine with
> > > CONFIG_EXT4_USE_FOR_EXT23 because ext3_fs_type maps to ext4_mount. My system is
> > > not built with CONFIG_EXT4_USE_FOR_EXT23 (long story short: it uses a RHEL6
> > > derived config on Linux 4.1) and I do not have time to rebuild it to verify my
> > > suspicion, but I imagine there are others on the list that could trivially check
> > > this.
> > 
> > On 4.2 with CONFIG_EXT4_USE_FOR_EXT23:
> > 
> > # mke2fs -T ext4 /dev/sda
> > # mount /dev/sda /mnt -t ext3
> > mount: wrong fs type, bad option, bad superblock on /dev/sda,
> >        missing codepage or helper program, or other error
> >        In some cases useful info is found in syslog - try
> >        dmesg | tail  or so
> > 
> > # lsmod|grep ext 
> > ext4                  630784  0 
> > jbd2                  126976  1 ext4
> > mbcache                20480  1 ext4
> > # dmesg
> > <snip>
> > [74559.632979] EXT4-fs (sda): couldn't mount as ext3 due to feature incompatibilities
> > 
> > > Also, new kernels are typically drop-in replacements on older userlands. An edge
> > > case that no one appears to have mentioned is the possibility of using a newer
> > > kernel on an older system where the initramfs generator might only include ext3,
> > > which this would break. It might not be terrible to write a small dummy ext3
> > > module whose only purpose is to depend on ext4 and load it into the kernel on
> > > those systems. That way initramfs software that properly grabs module
> > > dependencies will include the ext4 module and `modprobe ext3` will do what it
> > 
> > Well, if it goes looking for ext3.ko directly it will fail, but...
> > 
> > # modinfo ext3
> > filename:       /lib/modules/4.2.0-mcsum/kernel/fs/ext4/ext4.ko
> > license:        GPL
> > description:    Fourth Extended Filesystem
> > author:         Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
> > alias:          fs-ext4
> > alias:          ext3
> > alias:          fs-ext3
> > <snip>
> > 
> > I don't know about RHEL initrd scripts, but Ubuntu's use some modprobe trickery
> > which ensures that it picks up the correct ext4.ko.  It does something similar
> > to this:
> > 
> > # modprobe --ignore-install --quiet --show-depends ext3 | sed -e 's/^insmod //g'
> > /lib/modules/4.2.0-mcsum/kernel/fs/mbcache.ko 
> > /lib/modules/4.2.0-mcsum/kernel/fs/jbd2/jbd2.ko 
> > /lib/modules/4.2.0-mcsum/kernel/fs/ext4/ext4.ko
> > 
> > to pick up the modules for the initramfs.  Not sure what the other distros
> > do, though.
> 
> Unfortunately, the genkernel team was not aware of this when it wrote support
> for including kernel modules and I suspect others writing initramfs archive
> generators did not either.
> 
> https://gitweb.gentoo.org/proj/genkernel.git/tree/gen_initramfs.sh#n638
> https://gitweb.gentoo.org/proj/genkernel.git/tree/gen_moddeps.sh
> https://gitweb.gentoo.org/proj/genkernel.git/tree/defaults/modules_load
> 
> The way that works is that the module names are specified in a MODULES_*
> variable and then we search for dependencies based on what is specified in
> modules.dep. If you have an old enough version of the initramfs genreator, ext4
> is not specified and it will not recognize the alias.
> 
> I admit that this is likely a very rare edge case. I do not feel too strongly
> about breaking the older initramfs software. I just wanted to make sure others
> knew that they were.

Hmmm, is there no modules.alias on Gentoo?  That seems unlikely to me, but
I haven't run it in a while.  It's unfortunate that it doesn't get parsed
as part of initrd generation.

<shrug> I guess the initrd would break if you were trying to install a 4.3
kernel onto a pre-2010ish Gentoo rootfs, unless that file gets updated(?)

--D

> 
> > > always did in terms of making ext3 file systems mountable. I suppose that we
> > > could use aliases, but given that there is a compatibility shim for CONFIG_EXT3
> > > to avoid surprises, a dummy module seems reasonable.
> > > 
> > > These are the only two things that I see preventing ext4 from being a drop-in
> > > replacement for ext3.
> > > 
> > > That said, my only connection with ext3/ext4 is that I am one of the genkernel
> > > developers (Gentoo's  Linux initramfs/kernel genreation framework/scripts), so
> > > my opinion might not matter much here, but I am also in favor of killing ext3 in
> > > favor of CONFIG_EXT4_USE_FOR_EXT23.
> > 
> > :)
> > 
> > --D
> > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Ext3 removal, quota & udf fixes

[Richard Yao]

On Thu, Sep 03, 2015 at 12:36:08PM -0700, Darrick J. Wong wrote:
> On Thu, Sep 03, 2015 at 07:16:19PM +0000, Richard Yao wrote:
> > On Thu, Sep 03, 2015 at 11:36:57AM -0700, Darrick J. Wong wrote:
> > > On Thu, Sep 03, 2015 at 06:22:25PM +0000, Richard Yao wrote:
> > > > What happens with this patch if /dev/$DEVICE is ext4 formatted and someone runs
> > > > `mount -t ext3 /dev/$DEVICE $MNT`?
> > > > 
> > > > This should fail with the ext3 driver, but it looks like it will work fine with
> > > > CONFIG_EXT4_USE_FOR_EXT23 because ext3_fs_type maps to ext4_mount. My system is
> > > > not built with CONFIG_EXT4_USE_FOR_EXT23 (long story short: it uses a RHEL6
> > > > derived config on Linux 4.1) and I do not have time to rebuild it to verify my
> > > > suspicion, but I imagine there are others on the list that could trivially check
> > > > this.
> > > 
> > > On 4.2 with CONFIG_EXT4_USE_FOR_EXT23:
> > > 
> > > # mke2fs -T ext4 /dev/sda
> > > # mount /dev/sda /mnt -t ext3
> > > mount: wrong fs type, bad option, bad superblock on /dev/sda,
> > >        missing codepage or helper program, or other error
> > >        In some cases useful info is found in syslog - try
> > >        dmesg | tail  or so
> > > 
> > > # lsmod|grep ext 
> > > ext4                  630784  0 
> > > jbd2                  126976  1 ext4
> > > mbcache                20480  1 ext4
> > > # dmesg
> > > <snip>
> > > [74559.632979] EXT4-fs (sda): couldn't mount as ext3 due to feature incompatibilities
> > > 
> > > > Also, new kernels are typically drop-in replacements on older userlands. An edge
> > > > case that no one appears to have mentioned is the possibility of using a newer
> > > > kernel on an older system where the initramfs generator might only include ext3,
> > > > which this would break. It might not be terrible to write a small dummy ext3
> > > > module whose only purpose is to depend on ext4 and load it into the kernel on
> > > > those systems. That way initramfs software that properly grabs module
> > > > dependencies will include the ext4 module and `modprobe ext3` will do what it
> > > 
> > > Well, if it goes looking for ext3.ko directly it will fail, but...
> > > 
> > > # modinfo ext3
> > > filename:       /lib/modules/4.2.0-mcsum/kernel/fs/ext4/ext4.ko
> > > license:        GPL
> > > description:    Fourth Extended Filesystem
> > > author:         Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
> > > alias:          fs-ext4
> > > alias:          ext3
> > > alias:          fs-ext3
> > > <snip>
> > > 
> > > I don't know about RHEL initrd scripts, but Ubuntu's use some modprobe trickery
> > > which ensures that it picks up the correct ext4.ko.  It does something similar
> > > to this:
> > > 
> > > # modprobe --ignore-install --quiet --show-depends ext3 | sed -e 's/^insmod //g'
> > > /lib/modules/4.2.0-mcsum/kernel/fs/mbcache.ko 
> > > /lib/modules/4.2.0-mcsum/kernel/fs/jbd2/jbd2.ko 
> > > /lib/modules/4.2.0-mcsum/kernel/fs/ext4/ext4.ko
> > > 
> > > to pick up the modules for the initramfs.  Not sure what the other distros
> > > do, though.
> > 
> > Unfortunately, the genkernel team was not aware of this when it wrote support
> > for including kernel modules and I suspect others writing initramfs archive
> > generators did not either.
> > 
> > https://gitweb.gentoo.org/proj/genkernel.git/tree/gen_initramfs.sh#n638
> > https://gitweb.gentoo.org/proj/genkernel.git/tree/gen_moddeps.sh
> > https://gitweb.gentoo.org/proj/genkernel.git/tree/defaults/modules_load
> > 
> > The way that works is that the module names are specified in a MODULES_*
> > variable and then we search for dependencies based on what is specified in
> > modules.dep. If you have an old enough version of the initramfs genreator, ext4
> > is not specified and it will not recognize the alias.
> > 
> > I admit that this is likely a very rare edge case. I do not feel too strongly
> > about breaking the older initramfs software. I just wanted to make sure others
> > knew that they were.
> 
> Hmmm, is there no modules.alias on Gentoo?  That seems unlikely to me, but
> I haven't run it in a while.  It's unfortunate that it doesn't get parsed
> as part of initrd generation.

We have it in /lib/modules/$(unamr -r), but it was not used by genkernel in 2010
and is not used yet now. That will change soon, but it is not possible to go
back in time and patch things in 2010. The idea that ext3.ko would be removed
replaced via an alias had not occurred to anyone back then.

> <shrug> I guess the initrd would break if you were trying to install a 4.3
> kernel onto a pre-2010ish Gentoo rootfs, unless that file gets updated(?)

That is correct.

> --D
> 
> > 
> > > > always did in terms of making ext3 file systems mountable. I suppose that we
> > > > could use aliases, but given that there is a compatibility shim for CONFIG_EXT3
> > > > to avoid surprises, a dummy module seems reasonable.
> > > > 
> > > > These are the only two things that I see preventing ext4 from being a drop-in
> > > > replacement for ext3.
> > > > 
> > > > That said, my only connection with ext3/ext4 is that I am one of the genkernel
> > > > developers (Gentoo's  Linux initramfs/kernel genreation framework/scripts), so
> > > > my opinion might not matter much here, but I am also in favor of killing ext3 in
> > > > favor of CONFIG_EXT4_USE_FOR_EXT23.
> > > 
> > > :)
> > > 
> > > --D
> > > 
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html