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.
> >
> > Regards,
> > Salvatore
>
> Hi,
>
> I wrote this bug report because I assumed the release interval for forky as
> 2027
> -2030, which is within the kernel removal date for XFS V4 feature in 2030.
Debian stable releases are supported for 5 years on the most popular
architectures. So for forky this should be 2027-2032.
> 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?
I agree with Salvatore that this just needs to be documented.
Ben.
--
Ben Hutchings
A free society is one where it is safe to be unpopular.
- Adlai Stevenson
signature.asc
Description: This is a digitally signed message part
