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 1 of 2  [1] 2  Next page →

#1216032 — [GIT PULL] Ext3 removal, quota & udf fixes

  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
--
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] | [next] | [standalone]

#1216469

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

#1216500

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

#1216510

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

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

#1216565

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

#1216827

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
> 

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

#1216921

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

#1216502

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/

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

#1216534

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

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

#1216627

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

#1216752

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

#1217049

[Multipart message — attachments visible in raw view] — view raw

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.

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

#1217302

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

#1217325

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

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

#1217602

[Multipart message — attachments visible in raw view] — view raw

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.

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

#1217545

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

#1217605

[Multipart message — attachments visible in raw view] — view raw

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.

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

#1217735

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

#1217749

[Multipart message — attachments visible in raw view] — view raw

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.

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

#1216532

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





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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web