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@ubuntu.com vorlon@debian.org
