Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1216032 > unrolled thread

[GIT PULL] Ext3 removal, quota & udf fixes

Back to article view | Back to linux.kernel

Contents

  [GIT PULL] Ext3 removal, quota & udf fixes Jan Kara <jack@suse.cz> - 2015-08-31 08:20 +0200
    Re: [GIT PULL] Ext3 removal, quota & udf fixes Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-31 23:40 +0200
      Re: [GIT PULL] Ext3 removal, quota & udf fixes Linus Torvalds <torvalds@linux-foundation.org> - 2015-09-01 00:40 +0200
        Re: [GIT PULL] Ext3 removal, quota & udf fixes Raymond Jennings <shentino@gmail.com> - 2015-09-01 01:10 +0200
        Re: [GIT PULL] Ext3 removal, quota & udf fixes Theodore Ts'o <tytso@mit.edu> - 2015-09-01 05:00 +0200
        Re: [GIT PULL] Ext3 removal, quota & udf fixes Eric Sandeen <sandeen@redhat.com> - 2015-09-01 15:00 +0200
          Re: [GIT PULL] Ext3 removal, quota & udf fixes Jeff Mahoney <jeffm@suse.com> - 2015-09-01 17:20 +0200
      Re: [GIT PULL] Ext3 removal, quota & udf fixes Raymond Jennings <shentino@gmail.com> - 2015-09-01 00:40 +0200
        Re: [GIT PULL] Ext3 removal, quota & udf fixes Raymond Jennings <shentino@gmail.com> - 2015-09-01 02:30 +0200
        Re: [GIT PULL] Ext3 removal, quota & udf fixes Christoph Hellwig <hch@infradead.org> - 2015-09-01 08:50 +0200
        Re: [GIT PULL] Ext3 removal, quota & udf fixes Albino B Neto <bino@riseup.net> - 2015-09-01 12:30 +0200
          Re: [GIT PULL] Ext3 removal, quota & udf fixes Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-01 21:50 +0200
            Re: [GIT PULL] Ext3 removal, quota & udf fixes Albino B Neto <bino@riseup.net> - 2015-09-02 05:40 +0200
              Re: [GIT PULL] Ext3 removal, quota & udf fixes Raymond Jennings <shentino@gmail.com> - 2015-09-02 07:50 +0200
                Re: [GIT PULL] Ext3 removal, quota & udf fixes Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-02 15:30 +0200
            Re: [GIT PULL] Ext3 removal, quota & udf fixes Chuck Ebbert <cebbert.lkml@gmail.com> - 2015-09-02 14:00 +0200
              Re: [GIT PULL] Ext3 removal, quota & udf fixes Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-02 15:40 +0200
            Re: [GIT PULL] Ext3 removal, quota & udf fixes Theodore Ts'o <tytso@mit.edu> - 2015-09-02 18:30 +0200
              Re: [GIT PULL] Ext3 removal, quota & udf fixes Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-02 19:00 +0200
      Re: [GIT PULL] Ext3 removal, quota & udf fixes Andreas Dilger <adilger@dilger.ca> - 2015-09-01 02:30 +0200
      Re: [GIT PULL] Ext3 removal, quota & udf fixes Mel Gorman <mgorman@techsingularity.net> - 2015-09-02 19:00 +0200
        Re: [GIT PULL] Ext3 removal, quota & udf fixes "Darrick J. Wong" <darrick.wong@oracle.com> - 2015-09-02 20:50 +0200
          Re: [GIT PULL] Ext3 removal, quota & udf fixes Linus Torvalds <torvalds@linux-foundation.org> - 2015-09-03 01:50 +0200
            Re: [GIT PULL] Ext3 removal, quota & udf fixes Albino B Neto <bino@riseup.net> - 2015-09-03 13:40 +0200
              Re: [GIT PULL] Ext3 removal, quota & udf fixes "Darrick J. Wong" <darrick.wong@oracle.com> - 2015-09-03 23:50 +0200
    Re: [GIT PULL] Ext3 removal, quota & udf fixes Richard Yao <ryao@gentoo.org> - 2015-09-03 20:30 +0200
      Re: [GIT PULL] Ext3 removal, quota & udf fixes "Darrick J. Wong" <darrick.wong@oracle.com> - 2015-09-03 20:40 +0200
        Re: [GIT PULL] Ext3 removal, quota & udf fixes Richard Yao <ryao@gentoo.org> - 2015-09-03 21:20 +0200
          Re: [GIT PULL] Ext3 removal, quota & udf fixes "Darrick J. Wong" <darrick.wong@oracle.com> - 2015-09-03 21:40 +0200
            Re: [GIT PULL] Ext3 removal, quota & udf fixes Richard Yao <ryao@gentoo.org> - 2015-09-04 00:30 +0200
      Re: [GIT PULL] Ext3 removal, quota & udf fixes Eric Sandeen <sandeen@redhat.com> - 2015-09-03 20:40 +0200
        Re: [GIT PULL] Ext3 removal, quota & udf fixes Richard Yao <ryao@gentoo.org> - 2015-09-03 21:20 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1217752

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
--
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/

[toc] | [prev] | [next] | [standalone]

#1217803

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
--
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/

[toc] | [prev] | [next] | [standalone]

#1217949

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
--
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/

[toc] | [prev] | [next] | [standalone]

#1218182

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
--
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/

[toc] | [prev] | [next] | [standalone]

#1218593

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
--
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/

[toc] | [prev] | [next] | [standalone]

#1218496

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.
--
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/

[toc] | [prev] | [next] | [standalone]

#1218504

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
--
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/

[toc] | [prev] | [next] | [standalone]

#1218528

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
--
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/

[toc] | [prev] | [next] | [standalone]

#1218536

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
--
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/

[toc] | [prev] | [next] | [standalone]

#1218598

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
--
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/

[toc] | [prev] | [next] | [standalone]

#1218507

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
> 

--
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/

[toc] | [prev] | [next] | [standalone]

#1218525

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
> > 
> 
--
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/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web