ext4 metadata_csum and backwards compatibility

[Douglas Stanley]

On Mar 15, 2018 12:50 AM, "Steve Langasek" <steve.langasek at ubuntu.com>
wrote:

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.


I agree, documenting it should be good enough, but I also like option 3.
Mention in the documentation that a backported e2fsprogs is available.


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

--
ubuntu-server mailing list
ubuntu-server at lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20180315/f262e979/attachment-0001.html>