On Mar 15, 2018 12:50 AM, "Steve Langasek" <steve.langa...@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/ slanga...@ubuntu.com vor...@debian.org -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
-- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam