There are some Enterprise and Data-centre scenarios where this may cause
some pain.
1. iSCSI SAN where target and initiator are using incompatible versions
of e2fsprogs
2. LVM SAN (sanlock or DLM) where host and clients are using
incompatible versions
In both cases the problem arises where SAN
Hi All --
@Robie: Thanks for highlighting this problem.
+1 from me on just documenting in the release notes. It also seems a
reasonable enough *backport* if we want, but I don't think it's
necessary.
--
David Britton
--
ubuntu-devel mailing list
On Mon, Mar 19, 2018 at 02:36:05PM +0100, Julian Andres Klode wrote:
> I think it might be useful to snap e2fsprogs, so we have a solution
> for all older releases. Not to replace the package, but as a backport
> that does not conflict with the system binaries.
A snap wouldn't be a bad thing, but
On Mon, Mar 19, 2018 at 01:33:12PM +, Robie Basak wrote:
> On Wed, Mar 14, 2018 at 09:49:17PM -0700, Steve Langasek wrote:
> > 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
On 2018-03-14 07:17 AM, Robie Basak wrote:
> 3) We backport metadata_csum support to Xenial in an SRU[1] without
> changing the default there. Xenial users will be able to fsck
> Bionic-created ext4 filesystems. There will be forward compatibilty
> problems when skipping across multiple LTSs (eg.
On Wed, Mar 14, 2018 at 11:17:13AM +, 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
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