osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ext4 metadata_csum and backwards compatibility


On Wed, Mar 14, 2018 at 11:17:13AM +0000, Robie Basak wrote:
> I'd like to draw attention to:
> https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997

> IRC discussion:
> https://irclogs.ubuntu.com/2018/03/13/%23ubuntu-devel.html#t12:05

> tl;dr: by doing nothing we're implicitly breaking some filesystem
> forward compatibility. I'd like us to make an explicit decision about
> whether we want this.

> I think this probably doesn't matter in the desktop use case. Wearing my
> server hat, I think it'll impact more server users, so I'm also CC-ing
> the ubuntu-server list.

> Theodore Ts'o enabled metadata_csum in mke2fs by default in Debian "so
> that in the testing and unstable branches, metadadata_csum checking
> would get some additional exposure, and hence testing" (from the bug).
> At that time he said he hadn't decided if he wanted it there in time for
> the following Debian release. AFAICT, it was enabled by stretch. AIUI,
> Xenial's e2fsprogs currently has no support for metadata_csum at all.

> A consequence of this (I'm told) is that Xenial's e2fsck doesn't work
> against filesystems created by Bionic's installer. IOW, this change
> breaks forwards compatibility between LTSs for Ubuntu.

> I'm not aware that this kind of compatibility is a promise that we've
> ever made, but IME it is a reasonably common thing for sysadmins to want
> to do. IMHO, breaking compatibility like this is sometimes necessary but
> is certainly inconvenient.

> I would prefer us to make an explicit decision on this, rather than have
> it happen to us implicitly as a consequence of how our ecosystem works.

> Here are some options:

> 1) [the default if we do nothing] Bionic will have metadata_csum enabled
> in new filesystems by default. Xenial's e2fsck will not be able to act
> on Bionic-default-created ext4 filesystems.

<snip>

> I'm not keen on the default option 1 only because I have experiences of
> this kind of forward incompatibility being inconvenient for me in the
> past (when migrating systems in datacentres, etc). If the cost of
> maintaining at least some level of forward compatibility isn't too
> great, I would prefer that we keep it. If we do go with option 1 by
> doing nothing, I would at least like to release note this
> incompatibility.

It's not ideal for an interface to go from unsupported to mandatory in a
single LTS cycle; but I don't believe that the use case of creating a
filesystem with one LTS release, then interacting with it using the
userspace tools from a previous LTS release, is significant enough to
justify holding back features that upstream has recommended as the default.

I think it suffices to document this in the release notes.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20180314/6c1cc417/attachment.sig>