* [GIT PULL] Ext3 removal, quota & udf fixes @ 2015-08-31 6:19 Jan Kara 2015-08-31 21:37 ` Linus Torvalds 2015-09-03 18:22 ` Richard Yao 0 siblings, 2 replies; 33+ messages in thread From: Jan Kara @ 2015-08-31 6:19 UTC (permalink / raw) To: Linus Torvalds; +Cc: LKML, linux-ext4, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-08-31 6:19 [GIT PULL] Ext3 removal, quota & udf fixes Jan Kara @ 2015-08-31 21:37 ` Linus Torvalds 2015-08-31 22:31 ` Raymond Jennings ` (2 more replies) 2015-09-03 18:22 ` Richard Yao 1 sibling, 3 replies; 33+ messages in thread From: Linus Torvalds @ 2015-08-31 21:37 UTC (permalink / raw) To: Jan Kara; +Cc: LKML, linux-ext4, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-08-31 21:37 ` Linus Torvalds @ 2015-08-31 22:31 ` Raymond Jennings 2015-08-31 22:39 ` Linus Torvalds ` (3 more replies) 2015-09-01 0:23 ` Andreas Dilger 2015-09-02 16:52 ` Mel Gorman 2 siblings, 4 replies; 33+ messages in thread From: Raymond Jennings @ 2015-08-31 22:31 UTC (permalink / raw) To: Linus Torvalds, Jan Kara; +Cc: LKML, linux-ext4, linux-fsdevel 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/ ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-08-31 22:31 ` Raymond Jennings @ 2015-08-31 22:39 ` Linus Torvalds 2015-08-31 23:03 ` Raymond Jennings ` (2 more replies) 2015-09-01 0:24 ` Raymond Jennings ` (2 subsequent siblings) 3 siblings, 3 replies; 33+ messages in thread From: Linus Torvalds @ 2015-08-31 22:39 UTC (permalink / raw) To: Raymond Jennings; +Cc: Jan Kara, LKML, linux-ext4, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-08-31 22:39 ` Linus Torvalds @ 2015-08-31 23:03 ` Raymond Jennings 2015-09-01 2:53 ` Theodore Ts'o 2015-09-01 12:52 ` Eric Sandeen 2 siblings, 0 replies; 33+ messages in thread From: Raymond Jennings @ 2015-08-31 23:03 UTC (permalink / raw) To: Linus Torvalds; +Cc: Jan Kara, LKML, linux-ext4, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-08-31 22:39 ` Linus Torvalds 2015-08-31 23:03 ` Raymond Jennings @ 2015-09-01 2:53 ` Theodore Ts'o 2015-09-01 12:52 ` Eric Sandeen 2 siblings, 0 replies; 33+ messages in thread From: Theodore Ts'o @ 2015-09-01 2:53 UTC (permalink / raw) To: Linus Torvalds Cc: Raymond Jennings, Jan Kara, LKML, linux-ext4, linux-fsdevel 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-08-31 22:39 ` Linus Torvalds 2015-08-31 23:03 ` Raymond Jennings 2015-09-01 2:53 ` Theodore Ts'o @ 2015-09-01 12:52 ` Eric Sandeen 2015-09-01 15:17 ` Jeff Mahoney 2 siblings, 1 reply; 33+ messages in thread From: Eric Sandeen @ 2015-09-01 12:52 UTC (permalink / raw) To: Linus Torvalds, Raymond Jennings Cc: Jan Kara, LKML, linux-ext4, linux-fsdevel 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 > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-01 12:52 ` Eric Sandeen @ 2015-09-01 15:17 ` Jeff Mahoney 0 siblings, 0 replies; 33+ messages in thread From: Jeff Mahoney @ 2015-09-01 15:17 UTC (permalink / raw) To: Eric Sandeen, Linus Torvalds, Raymond Jennings Cc: Jan Kara, LKML, linux-ext4, linux-fsdevel -----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----- ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-08-31 22:31 ` Raymond Jennings 2015-08-31 22:39 ` Linus Torvalds @ 2015-09-01 0:24 ` Raymond Jennings 2015-09-01 6:44 ` Christoph Hellwig 2015-09-01 10:29 ` Albino B Neto 3 siblings, 0 replies; 33+ messages in thread From: Raymond Jennings @ 2015-09-01 0:24 UTC (permalink / raw) To: Linus Torvalds, Jan Kara; +Cc: LKML, linux-ext4, linux-fsdevel 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/ > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-08-31 22:31 ` Raymond Jennings 2015-08-31 22:39 ` Linus Torvalds 2015-09-01 0:24 ` Raymond Jennings @ 2015-09-01 6:44 ` Christoph Hellwig 2015-09-01 10:29 ` Albino B Neto 3 siblings, 0 replies; 33+ messages in thread From: Christoph Hellwig @ 2015-09-01 6:44 UTC (permalink / raw) To: Raymond Jennings Cc: Linus Torvalds, Jan Kara, LKML, linux-ext4, linux-fsdevel 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-08-31 22:31 ` Raymond Jennings ` (2 preceding siblings ...) 2015-09-01 6:44 ` Christoph Hellwig @ 2015-09-01 10:29 ` Albino B Neto 2015-09-01 19:39 ` Austin S Hemmelgarn 3 siblings, 1 reply; 33+ messages in thread From: Albino B Neto @ 2015-09-01 10:29 UTC (permalink / raw) To: Raymond Jennings Cc: Linus Torvalds, Jan Kara, LKML, linux-ext4, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-01 10:29 ` Albino B Neto @ 2015-09-01 19:39 ` Austin S Hemmelgarn 2015-09-01 23:58 ` Theodore Ts'o ` (2 more replies) 0 siblings, 3 replies; 33+ messages in thread From: Austin S Hemmelgarn @ 2015-09-01 19:39 UTC (permalink / raw) To: Albino B Neto, Raymond Jennings Cc: Linus Torvalds, Jan Kara, LKML, linux-ext4, linux-fsdevel [-- 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 --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-01 19:39 ` Austin S Hemmelgarn @ 2015-09-01 23:58 ` Theodore Ts'o 2015-09-02 16:58 ` Austin S Hemmelgarn 2015-09-02 3:30 ` Albino B Neto 2015-09-02 11:58 ` Chuck Ebbert 2 siblings, 1 reply; 33+ messages in thread From: Theodore Ts'o @ 2015-09-01 23:58 UTC (permalink / raw) To: Austin S Hemmelgarn Cc: Albino B Neto, Raymond Jennings, Linus Torvalds, Jan Kara, LKML, linux-ext4, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-01 23:58 ` Theodore Ts'o @ 2015-09-02 16:58 ` Austin S Hemmelgarn 0 siblings, 0 replies; 33+ messages in thread From: Austin S Hemmelgarn @ 2015-09-02 16:58 UTC (permalink / raw) To: Theodore Ts'o, Albino B Neto, Raymond Jennings, Linus Torvalds, Jan Kara, LKML, linux-ext4, linux-fsdevel [-- 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 --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-01 19:39 ` Austin S Hemmelgarn 2015-09-01 23:58 ` Theodore Ts'o @ 2015-09-02 3:30 ` Albino B Neto 2015-09-02 5:46 ` Raymond Jennings 2015-09-02 11:58 ` Chuck Ebbert 2 siblings, 1 reply; 33+ messages in thread From: Albino B Neto @ 2015-09-02 3:30 UTC (permalink / raw) To: Austin S Hemmelgarn Cc: Raymond Jennings, Linus Torvalds, Jan Kara, LKML, linux-ext4, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-02 3:30 ` Albino B Neto @ 2015-09-02 5:46 ` Raymond Jennings 2015-09-02 13:28 ` Austin S Hemmelgarn 0 siblings, 1 reply; 33+ messages in thread From: Raymond Jennings @ 2015-09-02 5:46 UTC (permalink / raw) To: Albino B Neto, Austin S Hemmelgarn Cc: Linus Torvalds, Jan Kara, LKML, linux-ext4, linux-fsdevel 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? > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-02 5:46 ` Raymond Jennings @ 2015-09-02 13:28 ` Austin S Hemmelgarn 0 siblings, 0 replies; 33+ messages in thread From: Austin S Hemmelgarn @ 2015-09-02 13:28 UTC (permalink / raw) To: Raymond Jennings, Albino B Neto Cc: Linus Torvalds, Jan Kara, LKML, linux-ext4, linux-fsdevel [-- 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 --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-01 19:39 ` Austin S Hemmelgarn 2015-09-01 23:58 ` Theodore Ts'o 2015-09-02 3:30 ` Albino B Neto @ 2015-09-02 11:58 ` Chuck Ebbert 2015-09-02 13:33 ` Austin S Hemmelgarn 2 siblings, 1 reply; 33+ messages in thread From: Chuck Ebbert @ 2015-09-02 11:58 UTC (permalink / raw) To: Austin S Hemmelgarn Cc: Albino B Neto, Raymond Jennings, Linus Torvalds, Jan Kara, LKML, linux-ext4, linux-fsdevel 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-02 11:58 ` Chuck Ebbert @ 2015-09-02 13:33 ` Austin S Hemmelgarn 0 siblings, 0 replies; 33+ messages in thread From: Austin S Hemmelgarn @ 2015-09-02 13:33 UTC (permalink / raw) To: Chuck Ebbert Cc: Albino B Neto, Raymond Jennings, Linus Torvalds, Jan Kara, LKML, linux-ext4, linux-fsdevel [-- 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 --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-08-31 21:37 ` Linus Torvalds 2015-08-31 22:31 ` Raymond Jennings @ 2015-09-01 0:23 ` Andreas Dilger 2015-09-02 16:52 ` Mel Gorman 2 siblings, 0 replies; 33+ messages in thread From: Andreas Dilger @ 2015-09-01 0:23 UTC (permalink / raw) To: Linus Torvalds; +Cc: Jan Kara, LKML, linux-ext4, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-08-31 21:37 ` Linus Torvalds 2015-08-31 22:31 ` Raymond Jennings 2015-09-01 0:23 ` Andreas Dilger @ 2015-09-02 16:52 ` Mel Gorman 2015-09-02 18:45 ` Darrick J. Wong 2 siblings, 1 reply; 33+ messages in thread From: Mel Gorman @ 2015-09-02 16:52 UTC (permalink / raw) To: Linus Torvalds; +Cc: Jan Kara, LKML, linux-ext4, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-02 16:52 ` Mel Gorman @ 2015-09-02 18:45 ` Darrick J. Wong 2015-09-02 23:47 ` Linus Torvalds 0 siblings, 1 reply; 33+ messages in thread From: Darrick J. Wong @ 2015-09-02 18:45 UTC (permalink / raw) To: Mel Gorman; +Cc: Linus Torvalds, Jan Kara, LKML, linux-ext4, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-02 18:45 ` Darrick J. Wong @ 2015-09-02 23:47 ` Linus Torvalds 2015-09-03 11:28 ` Albino B Neto 2015-09-15 5:31 ` Jan Kara 0 siblings, 2 replies; 33+ messages in thread From: Linus Torvalds @ 2015-09-02 23:47 UTC (permalink / raw) To: Darrick J. Wong; +Cc: Mel Gorman, Jan Kara, LKML, linux-ext4, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-02 23:47 ` Linus Torvalds @ 2015-09-03 11:28 ` Albino B Neto 2015-09-03 21:49 ` Darrick J. Wong 2015-09-15 5:31 ` Jan Kara 1 sibling, 1 reply; 33+ messages in thread From: Albino B Neto @ 2015-09-03 11:28 UTC (permalink / raw) To: Linus Torvalds Cc: Darrick J. Wong, Mel Gorman, Jan Kara, LKML, linux-ext4, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-03 11:28 ` Albino B Neto @ 2015-09-03 21:49 ` Darrick J. Wong 0 siblings, 0 replies; 33+ messages in thread From: Darrick J. Wong @ 2015-09-03 21:49 UTC (permalink / raw) To: Albino B Neto Cc: Linus Torvalds, Mel Gorman, Jan Kara, LKML, linux-ext4, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-02 23:47 ` Linus Torvalds 2015-09-03 11:28 ` Albino B Neto @ 2015-09-15 5:31 ` Jan Kara 1 sibling, 0 replies; 33+ messages in thread From: Jan Kara @ 2015-09-15 5:31 UTC (permalink / raw) To: Linus Torvalds Cc: Darrick J. Wong, Mel Gorman, Jan Kara, LKML, linux-ext4, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-08-31 6:19 [GIT PULL] Ext3 removal, quota & udf fixes Jan Kara 2015-08-31 21:37 ` Linus Torvalds @ 2015-09-03 18:22 ` Richard Yao 2015-09-03 18:36 ` Eric Sandeen 2015-09-03 18:36 ` Darrick J. Wong 1 sibling, 2 replies; 33+ messages in thread From: Richard Yao @ 2015-09-03 18:22 UTC (permalink / raw) To: Jan Kara Cc: LKML, linux-ext4, linux-fsdevel, Raymond Jennings, Linus Torvalds, Theodore Ts'o, Albino B Neto 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-03 18:22 ` Richard Yao @ 2015-09-03 18:36 ` Eric Sandeen 2015-09-03 19:13 ` Richard Yao 2015-09-03 18:36 ` Darrick J. Wong 1 sibling, 1 reply; 33+ messages in thread From: Eric Sandeen @ 2015-09-03 18:36 UTC (permalink / raw) To: Richard Yao, Jan Kara Cc: LKML, linux-ext4, linux-fsdevel, Raymond Jennings, Linus Torvalds, Theodore Ts'o, Albino B Neto 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 > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-03 18:36 ` Eric Sandeen @ 2015-09-03 19:13 ` Richard Yao 0 siblings, 0 replies; 33+ messages in thread From: Richard Yao @ 2015-09-03 19:13 UTC (permalink / raw) To: Eric Sandeen Cc: Jan Kara, LKML, linux-ext4, linux-fsdevel, Raymond Jennings, Linus Torvalds, Theodore Ts'o, Albino B Neto 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 > > > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-03 18:22 ` Richard Yao 2015-09-03 18:36 ` Eric Sandeen @ 2015-09-03 18:36 ` Darrick J. Wong 2015-09-03 19:16 ` Richard Yao 1 sibling, 1 reply; 33+ messages in thread From: Darrick J. Wong @ 2015-09-03 18:36 UTC (permalink / raw) To: Richard Yao Cc: Jan Kara, LKML, linux-ext4, linux-fsdevel, Raymond Jennings, Linus Torvalds, Theodore Ts'o, Albino B Neto 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-03 18:36 ` Darrick J. Wong @ 2015-09-03 19:16 ` Richard Yao 2015-09-03 19:36 ` Darrick J. Wong 0 siblings, 1 reply; 33+ messages in thread From: Richard Yao @ 2015-09-03 19:16 UTC (permalink / raw) To: Darrick J. Wong Cc: Jan Kara, LKML, linux-ext4, linux-fsdevel, Raymond Jennings, Linus Torvalds, Theodore Ts'o, Albino B Neto 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-03 19:16 ` Richard Yao @ 2015-09-03 19:36 ` Darrick J. Wong 2015-09-03 22:26 ` Richard Yao 0 siblings, 1 reply; 33+ messages in thread From: Darrick J. Wong @ 2015-09-03 19:36 UTC (permalink / raw) To: Richard Yao Cc: Jan Kara, LKML, linux-ext4, linux-fsdevel, Raymond Jennings, Linus Torvalds, Theodore Ts'o, Albino B Neto 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [GIT PULL] Ext3 removal, quota & udf fixes 2015-09-03 19:36 ` Darrick J. Wong @ 2015-09-03 22:26 ` Richard Yao 0 siblings, 0 replies; 33+ messages in thread From: Richard Yao @ 2015-09-03 22:26 UTC (permalink / raw) To: Darrick J. Wong Cc: Jan Kara, LKML, linux-ext4, linux-fsdevel, Raymond Jennings, Linus Torvalds, Theodore Ts'o, Albino B Neto 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2015-09-15 21:22 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-08-31 6:19 [GIT PULL] Ext3 removal, quota & udf fixes Jan Kara 2015-08-31 21:37 ` Linus Torvalds 2015-08-31 22:31 ` Raymond Jennings 2015-08-31 22:39 ` Linus Torvalds 2015-08-31 23:03 ` Raymond Jennings 2015-09-01 2:53 ` Theodore Ts'o 2015-09-01 12:52 ` Eric Sandeen 2015-09-01 15:17 ` Jeff Mahoney 2015-09-01 0:24 ` Raymond Jennings 2015-09-01 6:44 ` Christoph Hellwig 2015-09-01 10:29 ` Albino B Neto 2015-09-01 19:39 ` Austin S Hemmelgarn 2015-09-01 23:58 ` Theodore Ts'o 2015-09-02 16:58 ` Austin S Hemmelgarn 2015-09-02 3:30 ` Albino B Neto 2015-09-02 5:46 ` Raymond Jennings 2015-09-02 13:28 ` Austin S Hemmelgarn 2015-09-02 11:58 ` Chuck Ebbert 2015-09-02 13:33 ` Austin S Hemmelgarn 2015-09-01 0:23 ` Andreas Dilger 2015-09-02 16:52 ` Mel Gorman 2015-09-02 18:45 ` Darrick J. Wong 2015-09-02 23:47 ` Linus Torvalds 2015-09-03 11:28 ` Albino B Neto 2015-09-03 21:49 ` Darrick J. Wong 2015-09-15 5:31 ` Jan Kara 2015-09-03 18:22 ` Richard Yao 2015-09-03 18:36 ` Eric Sandeen 2015-09-03 19:13 ` Richard Yao 2015-09-03 18:36 ` Darrick J. Wong 2015-09-03 19:16 ` Richard Yao 2015-09-03 19:36 ` Darrick J. Wong 2015-09-03 22:26 ` Richard Yao
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.