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 <[email protected]>
SUSE Labs, CR
On Sun, Aug 30, 2015 at 11:19 PM, Jan Kara <[email protected]> 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
On 08/31/15 14:37, Linus Torvalds wrote:
> On Sun, Aug 30, 2015 at 11:19 PM, Jan Kara <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Mon, Aug 31, 2015 at 3:31 PM, Raymond Jennings <[email protected]> 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
On 08/31/15 15:39, Linus Torvalds wrote:
> On Mon, Aug 31, 2015 at 3:31 PM, Raymond Jennings <[email protected]> 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
On Aug 31, 2015, at 3:37 PM, Linus Torvalds <[email protected]> wrote:
>
> On Sun, Aug 30, 2015 at 11:19 PM, Jan Kara <[email protected]> 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
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 <[email protected]> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
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.