Quoting Ben Hutchings (2026-02-04 09:10:36)
> On Sat, 2026-01-31 at 12:26 +0100, 10dmar10 wrote:
> > Am 31.01.26 um 11:02 schrieb Salvatore Bonaccorso:
> > > Hi,
> > >
> > > On Sat, Jan 31, 2026 at 10:08:25AM +0100, 10dmar10 wrote:
> [...]
> > >> while no longer used by default, XFS V4 support is still useful for
> > accessing
> > >> legacy XFS V4 file systems as long as kernel supports it.
> > >
> > > This is correct, the default was changed in upstream with f69260511c69
> > > ("xfs: disable deprecated features by default in Kconfig") and I
> > > believe we should follow that within the forky release cycle.
> > >
> > > Thus for forky I do not think we should diverge here from the default
> > > and re-enable deprecated features, but probably we should document it
> > > at least in the release notes so that people upgrading from trixie to
> > > forky are awaere that V4 filesystems will not be supported anymore.
> > >
> > > A NEWS entry in the packaging itself might be a good idea as well.
>
> > Enabling CONFIG_XFS_SUPPORT_V4 would allow to continue running otherwise
> > perfectly fine existing legacy XFS V4 filesystems without unnecessary
> > breaking
> > anything within forky's release cycle...
>
> Those filesystems must be quite old at this point, since v5 appears to
> have been the default for new filesystems since xfsprogs 3.2.3 and
> Debian 9 "stretch". And they do need to be upgraded at some point due
> to the upstream EOL (and later, Y2038). How much would we gain by
> putting it off another 2 years?"Why break 7 year old filesystems in 4 years when we can break them today?" is a bizarre sentiment, especially when using upstream support involves a one-line change and nobody has written an upgrade path yet. Please let your users use upstream support.
signature.asc
Description: signature
