Keeping reiserfs in the tree has certain costs. For example, I would
very much like to remove the 'flags' argument to ->write_begin. We have
the infrastructure in place to handle AOP_FLAG_NOFS differently, but
AOP_FLAG_CONT_EXPAND is still around, used only by reiserfs.
Looking over the patches to reiserfs over the past couple of years, there
are fixes for a few syzbot reports and treewide changes. There don't
seem to be any fixes for user-spotted bugs since 2019. Does reiserfs
still have a large install base that is just very happy with an old
stable filesystem? Or have all its users migrated to new and exciting
filesystems with active feature development?
We've removed support for senescent filesystems before (ext, xiafs), so
it's not unprecedented. But while I have a clear idea of the benefits to
other developers of removing reiserfs, I don't have enough information to
weigh the costs to users. Maybe they're happy with having 5.15 support
for their reiserfs filesystems and can migrate to another filesystem
before they upgrade their kernel after 5.15.
Another possibility beyond outright removal would be to trim the kernel
code down to read-only support for reiserfs. Most of the quirks of
reiserfs have to do with write support, so this could be a useful way
forward. Again, I don't have a clear picture of how people actually
use reiserfs, so I don't know whether it is useful or not.
NB: Please don't discuss the personalities involved. This is purely a
"we have old code using old APIs" discussion.
On 02/20/2022 01:13 PM, Matthew Wilcox wrote:
> Keeping reiserfs in the tree has certain costs. For example, I would
> very much like to remove the 'flags' argument to ->write_begin. We have
> the infrastructure in place to handle AOP_FLAG_NOFS differently, but
> AOP_FLAG_CONT_EXPAND is still around, used only by reiserfs.
Please, consider the patch (next email in the thread) which drops that
flag from reiserfs.
Thanks,
Edward.
Hello!
On Sun 20-02-22 12:13:04, Matthew Wilcox wrote:
> Keeping reiserfs in the tree has certain costs. For example, I would
> very much like to remove the 'flags' argument to ->write_begin. We have
> the infrastructure in place to handle AOP_FLAG_NOFS differently, but
> AOP_FLAG_CONT_EXPAND is still around, used only by reiserfs.
>
> Looking over the patches to reiserfs over the past couple of years, there
> are fixes for a few syzbot reports and treewide changes. There don't
> seem to be any fixes for user-spotted bugs since 2019. Does reiserfs
> still have a large install base that is just very happy with an old
> stable filesystem? Or have all its users migrated to new and exciting
> filesystems with active feature development?
>
> We've removed support for senescent filesystems before (ext, xiafs), so
> it's not unprecedented. But while I have a clear idea of the benefits to
> other developers of removing reiserfs, I don't have enough information to
> weigh the costs to users. Maybe they're happy with having 5.15 support
> for their reiserfs filesystems and can migrate to another filesystem
> before they upgrade their kernel after 5.15.
>
> Another possibility beyond outright removal would be to trim the kernel
> code down to read-only support for reiserfs. Most of the quirks of
> reiserfs have to do with write support, so this could be a useful way
> forward. Again, I don't have a clear picture of how people actually
> use reiserfs, so I don't know whether it is useful or not.
>
> NB: Please don't discuss the personalities involved. This is purely a
> "we have old code using old APIs" discussion.
So from my distro experience installed userbase of reiserfs is pretty small
and shrinking. We still do build reiserfs in openSUSE / SLES kernels but
for enterprise offerings it is unsupported (for like 3-4 years) and the module
is not in the default kernel rpm anymore.
So clearly the filesystem is on the deprecation path, the question is
whether it is far enough to remove it from the kernel completely. Maybe
time to start deprecation by printing warnings when reiserfs gets mounted
and then if nobody yells for year or two, we'll go ahead and remove it?
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
On Tue, Feb 22, 2022 at 11:04:08AM +0100, Jan Kara wrote:
> Hello!
>
> On Sun 20-02-22 12:13:04, Matthew Wilcox wrote:
> > Keeping reiserfs in the tree has certain costs. For example, I would
> > very much like to remove the 'flags' argument to ->write_begin. We have
> > the infrastructure in place to handle AOP_FLAG_NOFS differently, but
> > AOP_FLAG_CONT_EXPAND is still around, used only by reiserfs.
> >
> > Looking over the patches to reiserfs over the past couple of years, there
> > are fixes for a few syzbot reports and treewide changes. There don't
> > seem to be any fixes for user-spotted bugs since 2019. Does reiserfs
> > still have a large install base that is just very happy with an old
> > stable filesystem? Or have all its users migrated to new and exciting
> > filesystems with active feature development?
> >
> > We've removed support for senescent filesystems before (ext, xiafs), so
> > it's not unprecedented. But while I have a clear idea of the benefits to
> > other developers of removing reiserfs, I don't have enough information to
> > weigh the costs to users. Maybe they're happy with having 5.15 support
> > for their reiserfs filesystems and can migrate to another filesystem
> > before they upgrade their kernel after 5.15.
> >
> > Another possibility beyond outright removal would be to trim the kernel
> > code down to read-only support for reiserfs. Most of the quirks of
> > reiserfs have to do with write support, so this could be a useful way
> > forward. Again, I don't have a clear picture of how people actually
> > use reiserfs, so I don't know whether it is useful or not.
> >
> > NB: Please don't discuss the personalities involved. This is purely a
> > "we have old code using old APIs" discussion.
>
> So from my distro experience installed userbase of reiserfs is pretty small
> and shrinking. We still do build reiserfs in openSUSE / SLES kernels but
> for enterprise offerings it is unsupported (for like 3-4 years) and the module
> is not in the default kernel rpm anymore.
>
> So clearly the filesystem is on the deprecation path, the question is
> whether it is far enough to remove it from the kernel completely. Maybe
> time to start deprecation by printing warnings when reiserfs gets mounted
> and then if nobody yells for year or two, we'll go ahead and remove it?
Yup, I'd say we should deprecate it and add it to the removal
schedule. The less poorly tested legacy filesystem code we have to
maintain the better.
Along those lines, I think we really need to be more aggressive
about deprecating and removing filesystems that cannot (or will not)
be made y2038k compliant in the new future. We're getting to close
to the point where long term distro and/or product development life
cycles will overlap with y2038k, so we should be thinking of
deprecating and removing such filesystems before they end up in
products that will still be in use in 15 years time.
And just so everyone in the discussion is aware: XFS already has a
deprecation and removal schedule for the non-y2038k-compliant v4
filesystem format. It's officially deprecated right now, we'll stop
building kernels with v4 support enabled by default in 2025, and
we're removing the code that supports the v4 format entirely in
2030.
Cheers,
Dave.
--
Dave Chinner
[email protected]
On Wed, 23 Feb 2022, Dave Chinner wrote:
> On Tue, Feb 22, 2022 at 11:04:08AM +0100, Jan Kara wrote:
>> Hello!
>>
>> On Sun 20-02-22 12:13:04, Matthew Wilcox wrote:
>>> Keeping reiserfs in the tree has certain costs. For example, I would
>>> very much like to remove the 'flags' argument to ->write_begin. We have
>>> the infrastructure in place to handle AOP_FLAG_NOFS differently, but
>>> AOP_FLAG_CONT_EXPAND is still around, used only by reiserfs.
>>>
>>> Looking over the patches to reiserfs over the past couple of years, there
>>> are fixes for a few syzbot reports and treewide changes. There don't
>>> seem to be any fixes for user-spotted bugs since 2019. Does reiserfs
>>> still have a large install base that is just very happy with an old
>>> stable filesystem? Or have all its users migrated to new and exciting
>>> filesystems with active feature development?
>>>
>>> We've removed support for senescent filesystems before (ext, xiafs), so
>>> it's not unprecedented. But while I have a clear idea of the benefits to
>>> other developers of removing reiserfs, I don't have enough information to
>>> weigh the costs to users. Maybe they're happy with having 5.15 support
>>> for their reiserfs filesystems and can migrate to another filesystem
>>> before they upgrade their kernel after 5.15.
>>>
>>> Another possibility beyond outright removal would be to trim the kernel
>>> code down to read-only support for reiserfs. Most of the quirks of
>>> reiserfs have to do with write support, so this could be a useful way
>>> forward. Again, I don't have a clear picture of how people actually
>>> use reiserfs, so I don't know whether it is useful or not.
>>>
>>> NB: Please don't discuss the personalities involved. This is purely a
>>> "we have old code using old APIs" discussion.
>>
>> So from my distro experience installed userbase of reiserfs is pretty small
>> and shrinking. We still do build reiserfs in openSUSE / SLES kernels but
>> for enterprise offerings it is unsupported (for like 3-4 years) and the module
>> is not in the default kernel rpm anymore.
>>
>> So clearly the filesystem is on the deprecation path, the question is
>> whether it is far enough to remove it from the kernel completely. Maybe
>> time to start deprecation by printing warnings when reiserfs gets mounted
>> and then if nobody yells for year or two, we'll go ahead and remove it?
>
> Yup, I'd say we should deprecate it and add it to the removal
> schedule. The less poorly tested legacy filesystem code we have to
> maintain the better.
>
> Along those lines, I think we really need to be more aggressive
> about deprecating and removing filesystems that cannot (or will not)
> be made y2038k compliant in the new future. We're getting to close
> to the point where long term distro and/or product development life
> cycles will overlap with y2038k, so we should be thinking of
> deprecating and removing such filesystems before they end up in
> products that will still be in use in 15 years time.
>
> And just so everyone in the discussion is aware: XFS already has a
> deprecation and removal schedule for the non-y2038k-compliant v4
> filesystem format. It's officially deprecated right now, we'll stop
> building kernels with v4 support enabled by default in 2025, and
> we're removing the code that supports the v4 format entirely in
> 2030.
For what it's worth, I have a number of production servers still using
Reiserfs, which I regularly maintain by upgrading to the latest Linux kernel
annually (mostly to apply security patches). I figured this filesystem would
still be available for several more years, since it's not quite y2038k yet.
I originally installed Reiserfs on these systems as early as 2005 due to the
tail-packing feature, which saved space with many small files on older
harddrives. Since then, I witnessed the development of ext4, and then btrfs.
For a long time, these newer filesystems had occasional reports of instabilities
and lost data, and so I shied away from using them. Meanwhile, Reiserfs reached
a level of maturity and no longer had active development on it, except for the
occasional bugfix. I felt this was a filesystem I could trust going forward
(despite its relative slowness), even after popular Linux distributions
eventually dropped it from being installed by default.
I have only recently begun to use XFS on newer installs, only since the XFS
developers added bigtime support for y2038k. But for existing installs, I ask
that we keep Reiserfs supported in the kernel a little longer. Perhaps use the
same deprecation schedule that was picked for XFS v4 (roughly 10 years of
deprecation before eventual removal)?
Thanks,
-Byron
On Wed, 23 Feb 2022, Byron Stanoszek wrote:
> On Wed, 23 Feb 2022, Dave Chinner wrote:
>> On Tue, Feb 22, 2022 at 11:04:08AM +0100, Jan Kara wrote:
>>> Hello!
>>>
>>> On Sun 20-02-22 12:13:04, Matthew Wilcox wrote:
>>>> Keeping reiserfs in the tree has certain costs. For example, I would
>>>> very much like to remove the 'flags' argument to ->write_begin. We have
>>>> the infrastructure in place to handle AOP_FLAG_NOFS differently, but
>>>> AOP_FLAG_CONT_EXPAND is still around, used only by reiserfs.
>>>>
>>>> Looking over the patches to reiserfs over the past couple of years,
>>>> there
>>>> are fixes for a few syzbot reports and treewide changes. There don't
>>>> seem to be any fixes for user-spotted bugs since 2019. Does reiserfs
>>>> still have a large install base that is just very happy with an old
>>>> stable filesystem? Or have all its users migrated to new and exciting
>>>> filesystems with active feature development?
>>>>
>>>> We've removed support for senescent filesystems before (ext, xiafs), so
>>>> it's not unprecedented. But while I have a clear idea of the benefits
>>>> to
>>>> other developers of removing reiserfs, I don't have enough information
>>>> to
>>>> weigh the costs to users. Maybe they're happy with having 5.15 support
>>>> for their reiserfs filesystems and can migrate to another filesystem
>>>> before they upgrade their kernel after 5.15.
>>>>
>>>> Another possibility beyond outright removal would be to trim the kernel
>>>> code down to read-only support for reiserfs. Most of the quirks of
>>>> reiserfs have to do with write support, so this could be a useful way
>>>> forward. Again, I don't have a clear picture of how people actually
>>>> use reiserfs, so I don't know whether it is useful or not.
>>>>
>>>> NB: Please don't discuss the personalities involved. This is purely a
>>>> "we have old code using old APIs" discussion.
>>>
>>> So from my distro experience installed userbase of reiserfs is pretty
>>> small
>>> and shrinking. We still do build reiserfs in openSUSE / SLES kernels but
>>> for enterprise offerings it is unsupported (for like 3-4 years) and the
>>> module
>>> is not in the default kernel rpm anymore.
>>>
>>> So clearly the filesystem is on the deprecation path, the question is
>>> whether it is far enough to remove it from the kernel completely. Maybe
>>> time to start deprecation by printing warnings when reiserfs gets mounted
>>> and then if nobody yells for year or two, we'll go ahead and remove it?
>>
>> Yup, I'd say we should deprecate it and add it to the removal
>> schedule. The less poorly tested legacy filesystem code we have to
>> maintain the better.
>>
>> Along those lines, I think we really need to be more aggressive
>> about deprecating and removing filesystems that cannot (or will not)
>> be made y2038k compliant in the new future. We're getting to close
>> to the point where long term distro and/or product development life
>> cycles will overlap with y2038k, so we should be thinking of
>> deprecating and removing such filesystems before they end up in
>> products that will still be in use in 15 years time.
>>
>> And just so everyone in the discussion is aware: XFS already has a
>> deprecation and removal schedule for the non-y2038k-compliant v4
>> filesystem format. It's officially deprecated right now, we'll stop
>> building kernels with v4 support enabled by default in 2025, and
>> we're removing the code that supports the v4 format entirely in
>> 2030.
>
> For what it's worth, I have a number of production servers still using
> Reiserfs, which I regularly maintain by upgrading to the latest Linux kernel
> annually (mostly to apply security patches). I figured this filesystem would
> still be available for several more years, since it's not quite y2038k yet.
>
> I originally installed Reiserfs on these systems as early as 2005 due to the
> tail-packing feature, which saved space with many small files on older
> harddrives. Since then, I witnessed the development of ext4, and then btrfs.
> For a long time, these newer filesystems had occasional reports of
> instabilities and lost data, and so I shied away from using them. Meanwhile,
> Reiserfs reached a level of maturity and no longer had active development on
> it, except for the occasional bugfix. I felt this was a filesystem I could
> trust going forward (despite its relative slowness), even after popular Linux
> distributions eventually dropped it from being installed by default.
>
> I have only recently begun to use XFS on newer installs, only since the XFS
> developers added bigtime support for y2038k. But for existing installs, I ask
> that we keep Reiserfs supported in the kernel a little longer. Perhaps use
> the same deprecation schedule that was picked for XFS v4 (roughly 10 years of
> deprecation before eventual removal)?
Sorry, I meant to say 5 years here, not 10.
Thanks,
-Byron
On Wed 23-02-22 09:48:26, Byron Stanoszek wrote:
> On Wed, 23 Feb 2022, Dave Chinner wrote:
> > On Tue, Feb 22, 2022 at 11:04:08AM +0100, Jan Kara wrote:
> > > Hello!
> > >
> > > On Sun 20-02-22 12:13:04, Matthew Wilcox wrote:
> > > > Keeping reiserfs in the tree has certain costs. For example, I would
> > > > very much like to remove the 'flags' argument to ->write_begin. We have
> > > > the infrastructure in place to handle AOP_FLAG_NOFS differently, but
> > > > AOP_FLAG_CONT_EXPAND is still around, used only by reiserfs.
> > > >
> > > > Looking over the patches to reiserfs over the past couple of years, there
> > > > are fixes for a few syzbot reports and treewide changes. There don't
> > > > seem to be any fixes for user-spotted bugs since 2019. Does reiserfs
> > > > still have a large install base that is just very happy with an old
> > > > stable filesystem? Or have all its users migrated to new and exciting
> > > > filesystems with active feature development?
> > > >
> > > > We've removed support for senescent filesystems before (ext, xiafs), so
> > > > it's not unprecedented. But while I have a clear idea of the benefits to
> > > > other developers of removing reiserfs, I don't have enough information to
> > > > weigh the costs to users. Maybe they're happy with having 5.15 support
> > > > for their reiserfs filesystems and can migrate to another filesystem
> > > > before they upgrade their kernel after 5.15.
> > > >
> > > > Another possibility beyond outright removal would be to trim the kernel
> > > > code down to read-only support for reiserfs. Most of the quirks of
> > > > reiserfs have to do with write support, so this could be a useful way
> > > > forward. Again, I don't have a clear picture of how people actually
> > > > use reiserfs, so I don't know whether it is useful or not.
> > > >
> > > > NB: Please don't discuss the personalities involved. This is purely a
> > > > "we have old code using old APIs" discussion.
> > >
> > > So from my distro experience installed userbase of reiserfs is pretty small
> > > and shrinking. We still do build reiserfs in openSUSE / SLES kernels but
> > > for enterprise offerings it is unsupported (for like 3-4 years) and the module
> > > is not in the default kernel rpm anymore.
> > >
> > > So clearly the filesystem is on the deprecation path, the question is
> > > whether it is far enough to remove it from the kernel completely. Maybe
> > > time to start deprecation by printing warnings when reiserfs gets mounted
> > > and then if nobody yells for year or two, we'll go ahead and remove it?
> >
> > Yup, I'd say we should deprecate it and add it to the removal
> > schedule. The less poorly tested legacy filesystem code we have to
> > maintain the better.
> >
> > Along those lines, I think we really need to be more aggressive
> > about deprecating and removing filesystems that cannot (or will not)
> > be made y2038k compliant in the new future. We're getting to close
> > to the point where long term distro and/or product development life
> > cycles will overlap with y2038k, so we should be thinking of
> > deprecating and removing such filesystems before they end up in
> > products that will still be in use in 15 years time.
> >
> > And just so everyone in the discussion is aware: XFS already has a
> > deprecation and removal schedule for the non-y2038k-compliant v4
> > filesystem format. It's officially deprecated right now, we'll stop
> > building kernels with v4 support enabled by default in 2025, and
> > we're removing the code that supports the v4 format entirely in
> > 2030.
>
> For what it's worth, I have a number of production servers still using
> Reiserfs, which I regularly maintain by upgrading to the latest Linux kernel
> annually (mostly to apply security patches). I figured this filesystem would
> still be available for several more years, since it's not quite y2038k yet.
>
> I originally installed Reiserfs on these systems as early as 2005 due to the
> tail-packing feature, which saved space with many small files on older
> harddrives. Since then, I witnessed the development of ext4, and then btrfs.
> For a long time, these newer filesystems had occasional reports of instabilities
> and lost data, and so I shied away from using them. Meanwhile, Reiserfs reached
> a level of maturity and no longer had active development on it, except for the
> occasional bugfix. I felt this was a filesystem I could trust going forward
> (despite its relative slowness), even after popular Linux distributions
> eventually dropped it from being installed by default.
>
> I have only recently begun to use XFS on newer installs, only since the XFS
> developers added bigtime support for y2038k. But for existing installs, I ask
> that we keep Reiserfs supported in the kernel a little longer. Perhaps use the
> same deprecation schedule that was picked for XFS v4 (roughly 10 years of
> deprecation before eventual removal)?
Thanks for letting us know about your usage! Frankly the reality of
reiserfs is that it gets practically no development time and little
testing. Now this would not be a big problem on its own because what used
to work should keep working but the rest of the common filesystem
infrastructure keeps moving (e.g. with Matthew's page cache changes, new
mount API, ...) and so it can happen that with a lack of testing &
development reiserfs will break without us noticing. So I would not
consider reiserfs a particularly safe choice these days and rather consider
migration to some other filesystem. Originally I thought about 2 years
deprecation period but if 5 years make things significantly easier for you
(here I have to admit I don't have experience with maintaining larger fleet
of servers and how much effort it takes to move it to a different fs) we can
live with that I guess.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
On Thu, 24 Feb 2022, Jan Kara wrote:
> On Wed 23-02-22 09:48:26, Byron Stanoszek wrote:
>> On Wed, 23 Feb 2022, Dave Chinner wrote:
>>> On Tue, Feb 22, 2022 at 11:04:08AM +0100, Jan Kara wrote:
>>>> Hello!
>>>>
>>>> On Sun 20-02-22 12:13:04, Matthew Wilcox wrote:
>>>>> Keeping reiserfs in the tree has certain costs. For example, I would
>>>>> very much like to remove the 'flags' argument to ->write_begin. We have
>>>>> the infrastructure in place to handle AOP_FLAG_NOFS differently, but
>>>>> AOP_FLAG_CONT_EXPAND is still around, used only by reiserfs.
>>>>>
>>>>> Looking over the patches to reiserfs over the past couple of years, there
>>>>> are fixes for a few syzbot reports and treewide changes. There don't
>>>>> seem to be any fixes for user-spotted bugs since 2019. Does reiserfs
>>>>> still have a large install base that is just very happy with an old
>>>>> stable filesystem? Or have all its users migrated to new and exciting
>>>>> filesystems with active feature development?
>>>>>
>>>>> We've removed support for senescent filesystems before (ext, xiafs), so
>>>>> it's not unprecedented. But while I have a clear idea of the benefits to
>>>>> other developers of removing reiserfs, I don't have enough information to
>>>>> weigh the costs to users. Maybe they're happy with having 5.15 support
>>>>> for their reiserfs filesystems and can migrate to another filesystem
>>>>> before they upgrade their kernel after 5.15.
>>>>>
>>>>> Another possibility beyond outright removal would be to trim the kernel
>>>>> code down to read-only support for reiserfs. Most of the quirks of
>>>>> reiserfs have to do with write support, so this could be a useful way
>>>>> forward. Again, I don't have a clear picture of how people actually
>>>>> use reiserfs, so I don't know whether it is useful or not.
>>>>>
>>>>> NB: Please don't discuss the personalities involved. This is purely a
>>>>> "we have old code using old APIs" discussion.
>>>>
>>>> So from my distro experience installed userbase of reiserfs is pretty small
>>>> and shrinking. We still do build reiserfs in openSUSE / SLES kernels but
>>>> for enterprise offerings it is unsupported (for like 3-4 years) and the module
>>>> is not in the default kernel rpm anymore.
>>>>
>>>> So clearly the filesystem is on the deprecation path, the question is
>>>> whether it is far enough to remove it from the kernel completely. Maybe
>>>> time to start deprecation by printing warnings when reiserfs gets mounted
>>>> and then if nobody yells for year or two, we'll go ahead and remove it?
>>>
>>> Yup, I'd say we should deprecate it and add it to the removal
>>> schedule. The less poorly tested legacy filesystem code we have to
>>> maintain the better.
>>>
>>> Along those lines, I think we really need to be more aggressive
>>> about deprecating and removing filesystems that cannot (or will not)
>>> be made y2038k compliant in the new future. We're getting to close
>>> to the point where long term distro and/or product development life
>>> cycles will overlap with y2038k, so we should be thinking of
>>> deprecating and removing such filesystems before they end up in
>>> products that will still be in use in 15 years time.
>>>
>>> And just so everyone in the discussion is aware: XFS already has a
>>> deprecation and removal schedule for the non-y2038k-compliant v4
>>> filesystem format. It's officially deprecated right now, we'll stop
>>> building kernels with v4 support enabled by default in 2025, and
>>> we're removing the code that supports the v4 format entirely in
>>> 2030.
>>
>> For what it's worth, I have a number of production servers still using
>> Reiserfs, which I regularly maintain by upgrading to the latest Linux kernel
>> annually (mostly to apply security patches). I figured this filesystem would
>> still be available for several more years, since it's not quite y2038k yet.
>>
>> I originally installed Reiserfs on these systems as early as 2005 due to the
>> tail-packing feature, which saved space with many small files on older
>> harddrives. Since then, I witnessed the development of ext4, and then btrfs.
>> For a long time, these newer filesystems had occasional reports of instabilities
>> and lost data, and so I shied away from using them. Meanwhile, Reiserfs reached
>> a level of maturity and no longer had active development on it, except for the
>> occasional bugfix. I felt this was a filesystem I could trust going forward
>> (despite its relative slowness), even after popular Linux distributions
>> eventually dropped it from being installed by default.
>>
>> I have only recently begun to use XFS on newer installs, only since the XFS
>> developers added bigtime support for y2038k. But for existing installs, I ask
>> that we keep Reiserfs supported in the kernel a little longer. Perhaps use the
>> same deprecation schedule that was picked for XFS v4 (roughly 10 years of
>> deprecation before eventual removal)?
>
> Thanks for letting us know about your usage! Frankly the reality of
> reiserfs is that it gets practically no development time and little
> testing. Now this would not be a big problem on its own because what used
> to work should keep working but the rest of the common filesystem
> infrastructure keeps moving (e.g. with Matthew's page cache changes, new
> mount API, ...) and so it can happen that with a lack of testing &
> development reiserfs will break without us noticing. So I would not
> consider reiserfs a particularly safe choice these days and rather consider
> migration to some other filesystem. Originally I thought about 2 years
> deprecation period but if 5 years make things significantly easier for you
> (here I have to admit I don't have experience with maintaining larger fleet
> of servers and how much effort it takes to move it to a different fs) we can
> live with that I guess.
I understand the necessity to drop uncommon or unmaintained subsystems in order
to keep moving forward with code development. And thanks for the warning
regarding reiserfs not being a particularly safe choice these days.
For my specific use case, I can probably squeeze by with 2 years of
deprecation, but I would feel more comfortable with having 3. Thanks for your
consideration!
Regards,
-Byron
On Wed, Feb 23, 2022 at 09:48:26AM -0500, Byron Stanoszek wrote:
> For what it's worth, I have a number of production servers still using
> Reiserfs, which I regularly maintain by upgrading to the latest Linux kernel
> annually (mostly to apply security patches). I figured this filesystem would
> still be available for several more years, since it's not quite y2038k yet.
Hey Byron, thanks for sharing your usage.
It's not entirely clear to me from your message whether you're aware
that our annual LTS release actually puts out new kernels every week (or
sometimes twice a week), and upgrades to the latest version are always
recommended. Those LTS kernels typically get five years of support in
total; indeed we just retired the v4.4 series earlier this month which
was originally released in January 2016, so it got six years of support.
If we dropped reiserfs from the kernel today (and thanks to Edward, we
don't have to), you'd still be able to use a v5.15 based kernel with
regular updates until 2028. If we drop it in two years, that should
take you through to 2030. Is that enough for your usage?
On Thu, 24 Feb 2022, Matthew Wilcox wrote:
> On Wed, Feb 23, 2022 at 09:48:26AM -0500, Byron Stanoszek wrote:
>> For what it's worth, I have a number of production servers still using
>> Reiserfs, which I regularly maintain by upgrading to the latest Linux kernel
>> annually (mostly to apply security patches). I figured this filesystem would
>> still be available for several more years, since it's not quite y2038k yet.
>
> Hey Byron, thanks for sharing your usage.
>
> It's not entirely clear to me from your message whether you're aware
> that our annual LTS release actually puts out new kernels every week (or
> sometimes twice a week), and upgrades to the latest version are always
> recommended. Those LTS kernels typically get five years of support in
> total; indeed we just retired the v4.4 series earlier this month which
> was originally released in January 2016, so it got six years of support.
>
> If we dropped reiserfs from the kernel today (and thanks to Edward, we
> don't have to), you'd still be able to use a v5.15 based kernel with
> regular updates until 2028. If we drop it in two years, that should
> take you through to 2030. Is that enough for your usage?
I'm aware of the LTS releases, but I hadn't thought about them in relation to
this issue. That's a good point, and so it sounds like I have nothing to worry
about.
Thanks for the recommendation.
Regards,
-Byron
On Fri, Feb 25, 2022 at 08:10:22AM -0500, Byron Stanoszek wrote:
> On Thu, 24 Feb 2022, Matthew Wilcox wrote:
> > On Wed, Feb 23, 2022 at 09:48:26AM -0500, Byron Stanoszek wrote:
> > > For what it's worth, I have a number of production servers still using
> > > Reiserfs, which I regularly maintain by upgrading to the latest Linux kernel
> > > annually (mostly to apply security patches). I figured this filesystem would
> > > still be available for several more years, since it's not quite y2038k yet.
> >
> > Hey Byron, thanks for sharing your usage.
> >
> > It's not entirely clear to me from your message whether you're aware
> > that our annual LTS release actually puts out new kernels every week (or
> > sometimes twice a week), and upgrades to the latest version are always
> > recommended. Those LTS kernels typically get five years of support in
> > total; indeed we just retired the v4.4 series earlier this month which
> > was originally released in January 2016, so it got six years of support.
> >
> > If we dropped reiserfs from the kernel today (and thanks to Edward, we
> > don't have to), you'd still be able to use a v5.15 based kernel with
> > regular updates until 2028. If we drop it in two years, that should
> > take you through to 2030. Is that enough for your usage?
>
> I'm aware of the LTS releases, but I hadn't thought about them in relation to
> this issue. That's a good point, and so it sounds like I have nothing to worry
> about.
This just makes me think that instead of speaking about deprecation in
terms of version, speaking in terms of dates might be more suitable, as
it should help discouraging distros or products shipping LTS kernels
from enabling such deprecated features: when you're told the features
will disappear after, say, 5.20, some might think "OK 5.20 is the last
one and it happens to be LTS so I get the feature for 6 extra years
after it's EOL".
But if instead it's said "will not pass 2023", it's easier to understand
that it must not be shipped anymore even with todays kernels if the
intent is to place them in products for a long time.
Just my two cents,
Willy
On Fri, Feb 25, 2022 at 02:23:00PM +0100, Willy Tarreau wrote:
> On Fri, Feb 25, 2022 at 08:10:22AM -0500, Byron Stanoszek wrote:
> > On Thu, 24 Feb 2022, Matthew Wilcox wrote:
> > > On Wed, Feb 23, 2022 at 09:48:26AM -0500, Byron Stanoszek wrote:
> > > > For what it's worth, I have a number of production servers still using
> > > > Reiserfs, which I regularly maintain by upgrading to the latest Linux kernel
> > > > annually (mostly to apply security patches). I figured this filesystem would
> > > > still be available for several more years, since it's not quite y2038k yet.
> > >
> > > Hey Byron, thanks for sharing your usage.
> > >
> > > It's not entirely clear to me from your message whether you're aware
> > > that our annual LTS release actually puts out new kernels every week (or
> > > sometimes twice a week), and upgrades to the latest version are always
> > > recommended. Those LTS kernels typically get five years of support in
> > > total; indeed we just retired the v4.4 series earlier this month which
> > > was originally released in January 2016, so it got six years of support.
> > >
> > > If we dropped reiserfs from the kernel today (and thanks to Edward, we
> > > don't have to), you'd still be able to use a v5.15 based kernel with
> > > regular updates until 2028. If we drop it in two years, that should
> > > take you through to 2030. Is that enough for your usage?
> >
> > I'm aware of the LTS releases, but I hadn't thought about them in relation to
> > this issue. That's a good point, and so it sounds like I have nothing to worry
> > about.
>
> This just makes me think that instead of speaking about deprecation in
> terms of version, speaking in terms of dates might be more suitable, as
> it should help discouraging distros or products shipping LTS kernels
> from enabling such deprecated features: when you're told the features
> will disappear after, say, 5.20, some might think "OK 5.20 is the last
> one and it happens to be LTS so I get the feature for 6 extra years
> after it's EOL".
This is exactly why the XFS deprecation schedules are dated while
the actual removals record kernel releases. If it gets released in
a kernel, then it technically is supported for the life of that
kernel, even if it is a LTS kernel and the functionality no long
exists upstream.
That is, we know that once we've removed something from upstream,
it's still going to be actively used in LTS kernels based on kernels
that still have that functionality. Same goes for enterprise
kernels. Hence deprecation policies need to first acknowledge the
typical "no regressions" policies for LTS kernels...
With that in mind, this is why we've already deprecated non-y2038k
compliant functionality in XFS so that enterprise kernels can mark
it deprecated in their next major (N + 1) release which will be
supported for 10 years. They can then remove that support it in the
N+2 major release after that (which is probably at least 5 years
down the track) so that the support window for non-compliant
functionality does not run past y2038k.
We chose this specifically because most of the XFS developers are
also responsible for maintaining enterprise distro kernels, and so
we always thinking about how we are going to maintain the upstream
code we release today because it will have a 10-15 year active
support life. This is also why the deprecation notice in
Documentation/admin-guide/xfs.rst has this caveat:
Note: Distributors may choose to withdraw V4 format support earlier than
the dates listed above.
Distros might chose to remove deprecated functionality immediately
rather than rely on, say, LTS kernel support for functionality that
upstream developers are clearly not focussing their efforts on
developing further.
Hence we have to acknowledge that fact that once upstream has
deprecated a feature, it's up to distros to decide how they want to
handle long term support for that feature. The upstream LTS kernel
maintainers are going to have to decide on their own policy, too,
because we cannot bind upstream maintenance decisions on random
individual downstream support constraints. Downstream has to choose
for itself how it handles upstream deprecation notices but, that
said, upstream developers also need to listen to downstream distro
support and deprecation requirements...
Cheers,
Dave.
--
Dave Chinner
[email protected]
On Sat, Feb 26, 2022 at 09:56:00AM +1100, Dave Chinner wrote:
>
> Hence we have to acknowledge that fact that once upstream has
> deprecated a feature, it's up to distros to decide how they want to
> handle long term support for that feature. The upstream LTS kernel
> maintainers are going to have to decide on their own policy, too,
> because we cannot bind upstream maintenance decisions on random
> individual downstream support constraints. Downstream has to choose
> for itself how it handles upstream deprecation notices but, that
> said, upstream developers also need to listen to downstream distro
> support and deprecation requirements...
This is as it should be. It might not make a difference for reiserfs,
where the development efforts is largely dead already, but once
upstream deprecates a feature, the distributions can no longer rely on
upstream developers to fix a critical stability or security bug in
upstream, so it can be backported into an LTS or stable distro kernel.
They are on their own.
The bug might even be fixed in one enterprise distro's kernel product,
but an isolated patch might not be available; only a megapatch of all
of the distro's changes afgainst an upstrema kernel as a single
un-broken-out-and-GPL-compliant patch. So a critical bugfix present
in one distro release might not be so easily carried over to another
distro.
So that's an important thing to remember; an LTS kernel as a whole
might be "supported" by a stable kernel team from a backports
perspective for years, but that doesn't mean that a deprecated feature
or subsystem is going to be receiving upstream support, and it's fair
that this be advertised so that users and distributions can make their
own decisions about how long they want to use or support a deprecated
feature or subsystem on a downstream basis.
- Ted
Hi!
On Thu 17-03-22 09:53:22, Thomas Dreibholz wrote:
> I just noticed the thread about ReiserFS deprecation. We are currently still
> using ReiserFS on ca. 50 production machines of the NorNet Core
> infrastructure (https://www.nntb.no/). While newer machines use BTRFS
> instead, the older machines had ReiserFS used, due to its stability and
> better performance in comparison to ext4. At their installation time, we did
> not consider BTRFS being mature enough. A deprecation period of ca. 5 years
> from now seems to be reasonable, although it would be nice to have at least
> a read-only capability available for some longer time, for the case it
> becomes necessary to read an old ReiserFS file system on a newer system.
Thanks for your feedback! So the current plan is to remove the support from
current upstream kernel in ~3 years, as people noted, you can still use
upstream -stable kernels branched at the end of the deprecation period for
another two years which gives you around 5 years to migrate if you are
using upstream stable kernels.
You can still use sufficiently old kernel (VM?) or FUSE (although someone
motivated would probably need to write proper support module but e.g. grub2
has reiserfs support in userspace implemented) to get data out of
Reiserfs partitions after that... At least that's the current plan.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
Hi,
I just noticed the thread about ReiserFS deprecation. We are currently
still using ReiserFS on ca. 50 production machines of the NorNet Core
infrastructure (https://www.nntb.no/). While newer machines use BTRFS
instead, the older machines had ReiserFS used, due to its stability and
better performance in comparison to ext4. At their installation time, we
did not consider BTRFS being mature enough. A deprecation period of ca.
5 years from now seems to be reasonable, although it would be nice to
have at least a read-only capability available for some longer time, for
the case it becomes necessary to read an old ReiserFS file system on a
newer system.
--
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen
=======================================================================
Thomas Dreibholz
SimulaMet — Simula Metropolitan Centre for Digital Engineering
Centre for Resilient Networks and Applications
Pilestredet 52
0167 Oslo, Norway
-----------------------------------------------------------------------
E-Mail: [email protected]
Homepage: http://simula.no/people/dreibh
=======================================================================
Hi!
> > Keeping reiserfs in the tree has certain costs. For example, I would
> > very much like to remove the 'flags' argument to ->write_begin. We have
> > the infrastructure in place to handle AOP_FLAG_NOFS differently, but
> > AOP_FLAG_CONT_EXPAND is still around, used only by reiserfs.
> >
> > Looking over the patches to reiserfs over the past couple of years, there
> > are fixes for a few syzbot reports and treewide changes. There don't
> > seem to be any fixes for user-spotted bugs since 2019. Does reiserfs
> > still have a large install base that is just very happy with an old
> > stable filesystem? Or have all its users migrated to new and exciting
> > filesystems with active feature development?
> >
> > We've removed support for senescent filesystems before (ext, xiafs), so
> > it's not unprecedented. But while I have a clear idea of the benefits to
> > other developers of removing reiserfs, I don't have enough information to
> > weigh the costs to users. Maybe they're happy with having 5.15 support
> > for their reiserfs filesystems and can migrate to another filesystem
> > before they upgrade their kernel after 5.15.
> >
> > Another possibility beyond outright removal would be to trim the kernel
> > code down to read-only support for reiserfs. Most of the quirks of
> > reiserfs have to do with write support, so this could be a useful way
> > forward. Again, I don't have a clear picture of how people actually
> > use reiserfs, so I don't know whether it is useful or not.
> >
> > NB: Please don't discuss the personalities involved. This is purely a
> > "we have old code using old APIs" discussion.
>
> So from my distro experience installed userbase of reiserfs is pretty small
> and shrinking. We still do build reiserfs in openSUSE / SLES kernels but
> for enterprise offerings it is unsupported (for like 3-4 years) and the module
> is not in the default kernel rpm anymore.
I believe I've seen reiserfs in recent Arch Linux ARM installation on
PinePhone. I don't really think you can remove a feature people are
using.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
> > So from my distro experience installed userbase of reiserfs is pretty small
> > and shrinking. We still do build reiserfs in openSUSE / SLES kernels but
> > for enterprise offerings it is unsupported (for like 3-4 years) and the module
> > is not in the default kernel rpm anymore.
> >
> > So clearly the filesystem is on the deprecation path, the question is
> > whether it is far enough to remove it from the kernel completely. Maybe
> > time to start deprecation by printing warnings when reiserfs gets mounted
> > and then if nobody yells for year or two, we'll go ahead and remove it?
>
> Yup, I'd say we should deprecate it and add it to the removal
> schedule. The less poorly tested legacy filesystem code we have to
> maintain the better.
>
> Along those lines, I think we really need to be more aggressive
> about deprecating and removing filesystems that cannot (or will not)
> be made y2038k compliant in the new future. We're getting to close
> to the point where long term distro and/or product development life
> cycles will overlap with y2038k, so we should be thinking of
> deprecating and removing such filesystems before they end up in
> products that will still be in use in 15 years time.
>
> And just so everyone in the discussion is aware: XFS already has a
> deprecation and removal schedule for the non-y2038k-compliant v4
> filesystem format. It's officially deprecated right now, we'll stop
> building kernels with v4 support enabled by default in 2025, and
> we're removing the code that supports the v4 format entirely in
> 2030.
Haha.
It is not up to you. You can't remove feature people are
using. Sorry. Talk to Linus about that.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
Hi!
> > But I believe userbase is bigger than you think and it will not be
> > possible to remove reiserfs anytime soon.
>
> I was about to say the opposite until I noticed that one of my main
> dev machine has its kernel git dir on it because it's an old FS from
> a previous instance of this machine before an upgrade and it turns out
> that this FS still had lots of available space to store git trees
> :-/
:-).
> So maybe you're right and there are still a bit more than expected out
> there. However I really think that most users who still have one are in
> the same situation as I am, they're not aware of it. So aside big fat
> warnings at mount time (possibly with an extra delay), there's nothing
> that will make that situation change.
>
> At the very least disabling it by default in Kconfig and in distros
> should be effective. I really don't think that there are still users
> who regularly update their system and who have it on their rootfs, but
> still having data on it, yes, possibly. The earlier they're warned,
> the better.
I guess we should start by making sure that distributions don't use it
by default. Big fat warning + delay is a bit harsh for that, talking
to them should be enough at this point :-).
Someone start with Arch Linux ARM.
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
On Mon 04-04-22 12:18:02, Willy Tarreau wrote:
> Hi Pavel,
>
> On Mon, Apr 04, 2022 at 12:07:32PM +0200, Pavel Machek wrote:
> > > Well, if someone uses Reiserfs they better either migrate to some other
> > > filesystem or start maintaining it. It is as simple as that because
> > > currently there's nobody willing to invest resources in it for quite a few
> > > years and so it is just a question of time before it starts eating people's
> > > data (probably it already does in some cornercases, as an example there are
> > > quite some syzbot reports for it)...
> >
> > Yes people should migrate away from Reiserfs. I guess someone should
> > break the news to Arch Linux ARM people.
> >
> > But I believe userbase is bigger than you think and it will not be
> > possible to remove reiserfs anytime soon.
>
> I was about to say the opposite until I noticed that one of my main
> dev machine has its kernel git dir on it because it's an old FS from
> a previous instance of this machine before an upgrade and it turns out
> that this FS still had lots of available space to store git trees :-/
:)
> So maybe you're right and there are still a bit more than expected out
> there. However I really think that most users who still have one are in
> the same situation as I am, they're not aware of it. So aside big fat
> warnings at mount time (possibly with an extra delay), there's nothing
> that will make that situation change.
>
> At the very least disabling it by default in Kconfig and in distros
> should be effective. I really don't think that there are still users
> who regularly update their system and who have it on their rootfs, but
> still having data on it, yes, possibly. The earlier they're warned,
> the better.
Yes, we start with a warning now. Say a year before we really do remove it,
my plan is to refuse to mount it unless you pass a "I really know what I'm
doing" mount option so that we make sure people who possibly missed a
warning until that moment are aware of the deprecation and still have an
easy path and some time to migrate.
Regarding distros, I know that SUSE (and likely RH) do not offer reiserfs
in their installers for quite some time, it is unsupported for the
enterprise offerings (so most if not all paying customers have migrated
away from it). The notice was in LWN, Slashdot, and perhaps other news
sites so perhaps other distro maintainers do notice sooner rather than
later. I can specifically try to reach to Arch Linux given Pavel's notice
to give them some early warning.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
On Mon, Apr 04, 2022 at 02:55:41PM +0200, Jan Kara wrote:
> Yes, we start with a warning now. Say a year before we really do remove it,
> my plan is to refuse to mount it unless you pass a "I really know what I'm
> doing" mount option so that we make sure people who possibly missed a
> warning until that moment are aware of the deprecation and still have an
> easy path and some time to migrate.
That's a good idea. I was thinking as well about something manual (e.g.
manually modprobe the FS) but an option will be even better.
Willy
Hi Pavel,
On Mon, Apr 04, 2022 at 12:07:32PM +0200, Pavel Machek wrote:
> > Well, if someone uses Reiserfs they better either migrate to some other
> > filesystem or start maintaining it. It is as simple as that because
> > currently there's nobody willing to invest resources in it for quite a few
> > years and so it is just a question of time before it starts eating people's
> > data (probably it already does in some cornercases, as an example there are
> > quite some syzbot reports for it)...
>
> Yes people should migrate away from Reiserfs. I guess someone should
> break the news to Arch Linux ARM people.
>
> But I believe userbase is bigger than you think and it will not be
> possible to remove reiserfs anytime soon.
I was about to say the opposite until I noticed that one of my main
dev machine has its kernel git dir on it because it's an old FS from
a previous instance of this machine before an upgrade and it turns out
that this FS still had lots of available space to store git trees :-/
So maybe you're right and there are still a bit more than expected out
there. However I really think that most users who still have one are in
the same situation as I am, they're not aware of it. So aside big fat
warnings at mount time (possibly with an extra delay), there's nothing
that will make that situation change.
At the very least disabling it by default in Kconfig and in distros
should be effective. I really don't think that there are still users
who regularly update their system and who have it on their rootfs, but
still having data on it, yes, possibly. The earlier they're warned,
the better.
At least now I know I need to migrate this FS.
Regards,
Willy
Hello!
On Sat 02-04-22 12:54:55, Pavel Machek wrote:
> > > Keeping reiserfs in the tree has certain costs. For example, I would
> > > very much like to remove the 'flags' argument to ->write_begin. We have
> > > the infrastructure in place to handle AOP_FLAG_NOFS differently, but
> > > AOP_FLAG_CONT_EXPAND is still around, used only by reiserfs.
> > >
> > > Looking over the patches to reiserfs over the past couple of years, there
> > > are fixes for a few syzbot reports and treewide changes. There don't
> > > seem to be any fixes for user-spotted bugs since 2019. Does reiserfs
> > > still have a large install base that is just very happy with an old
> > > stable filesystem? Or have all its users migrated to new and exciting
> > > filesystems with active feature development?
> > >
> > > We've removed support for senescent filesystems before (ext, xiafs), so
> > > it's not unprecedented. But while I have a clear idea of the benefits to
> > > other developers of removing reiserfs, I don't have enough information to
> > > weigh the costs to users. Maybe they're happy with having 5.15 support
> > > for their reiserfs filesystems and can migrate to another filesystem
> > > before they upgrade their kernel after 5.15.
> > >
> > > Another possibility beyond outright removal would be to trim the kernel
> > > code down to read-only support for reiserfs. Most of the quirks of
> > > reiserfs have to do with write support, so this could be a useful way
> > > forward. Again, I don't have a clear picture of how people actually
> > > use reiserfs, so I don't know whether it is useful or not.
> > >
> > > NB: Please don't discuss the personalities involved. This is purely a
> > > "we have old code using old APIs" discussion.
> >
> > So from my distro experience installed userbase of reiserfs is pretty small
> > and shrinking. We still do build reiserfs in openSUSE / SLES kernels but
> > for enterprise offerings it is unsupported (for like 3-4 years) and the module
> > is not in the default kernel rpm anymore.
>
> I believe I've seen reiserfs in recent Arch Linux ARM installation on
> PinePhone. I don't really think you can remove a feature people are
> using.
Well, if someone uses Reiserfs they better either migrate to some other
filesystem or start maintaining it. It is as simple as that because
currently there's nobody willing to invest resources in it for quite a few
years and so it is just a question of time before it starts eating people's
data (probably it already does in some cornercases, as an example there are
quite some syzbot reports for it)...
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
Hello!
On Mon 04-04-22 12:58:28, Pavel Machek wrote:
> > So maybe you're right and there are still a bit more than expected out
> > there. However I really think that most users who still have one are in
> > the same situation as I am, they're not aware of it. So aside big fat
> > warnings at mount time (possibly with an extra delay), there's nothing
> > that will make that situation change.
> >
> > At the very least disabling it by default in Kconfig and in distros
> > should be effective. I really don't think that there are still users
> > who regularly update their system and who have it on their rootfs, but
> > still having data on it, yes, possibly. The earlier they're warned,
> > the better.
>
> I guess we should start by making sure that distributions don't use it
> by default. Big fat warning + delay is a bit harsh for that, talking
> to them should be enough at this point :-).
>
> Someone start with Arch Linux ARM.
Yeah, I will write them and CC you. Thanks for notifying me.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
Hi!
> > > So from my distro experience installed userbase of reiserfs is pretty small
> > > and shrinking. We still do build reiserfs in openSUSE / SLES kernels but
> > > for enterprise offerings it is unsupported (for like 3-4 years) and the module
> > > is not in the default kernel rpm anymore.
> >
> > I believe I've seen reiserfs in recent Arch Linux ARM installation on
> > PinePhone. I don't really think you can remove a feature people are
> > using.
>
> Well, if someone uses Reiserfs they better either migrate to some other
> filesystem or start maintaining it. It is as simple as that because
> currently there's nobody willing to invest resources in it for quite a few
> years and so it is just a question of time before it starts eating people's
> data (probably it already does in some cornercases, as an example there are
> quite some syzbot reports for it)...
Yes people should migrate away from Reiserfs. I guess someone should
break the news to Arch Linux ARM people.
But I believe userbase is bigger than you think and it will not be
possible to remove reiserfs anytime soon.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
On Sat, Apr 02, 2022 at 12:57:49PM +0200, Pavel Machek wrote:
> > > So from my distro experience installed userbase of reiserfs is pretty small
> > > and shrinking. We still do build reiserfs in openSUSE / SLES kernels but
> > > for enterprise offerings it is unsupported (for like 3-4 years) and the module
> > > is not in the default kernel rpm anymore.
> > >
> > > So clearly the filesystem is on the deprecation path, the question is
> > > whether it is far enough to remove it from the kernel completely. Maybe
> > > time to start deprecation by printing warnings when reiserfs gets mounted
> > > and then if nobody yells for year or two, we'll go ahead and remove it?
> >
> > Yup, I'd say we should deprecate it and add it to the removal
> > schedule. The less poorly tested legacy filesystem code we have to
> > maintain the better.
> >
> > Along those lines, I think we really need to be more aggressive
> > about deprecating and removing filesystems that cannot (or will not)
> > be made y2038k compliant in the new future. We're getting to close
> > to the point where long term distro and/or product development life
> > cycles will overlap with y2038k, so we should be thinking of
> > deprecating and removing such filesystems before they end up in
> > products that will still be in use in 15 years time.
> >
> > And just so everyone in the discussion is aware: XFS already has a
> > deprecation and removal schedule for the non-y2038k-compliant v4
> > filesystem format. It's officially deprecated right now, we'll stop
> > building kernels with v4 support enabled by default in 2025, and
> > we're removing the code that supports the v4 format entirely in
> > 2030.
>
> Haha.
>
> It is not up to you. You can't remove feature people are
> using. Sorry. Talk to Linus about that.
I think you have the wrong end of the stick. We're not removing
stuff that people use, we're removing support for functionality that
will be *fundamentally broken* and *unfixable* come 2038. Hence we
need a process for ensuring that nobody is still requiring us to
support it by the scheduled removal date.
Every long term project needs to have a deprecation process so that
they can clean out unmaintained, broken, unfixable and/or unused
code without putting users at risk. If we can't/won't/don't clear
out unmaintained or unfixable code, the risk of data loss, security
breaches, etc in that code is a real and present danger to
any kernel that includes that code. We learnt this lesson the hard
way recently, and we simply removed the legacy code responsible in
response. Even Linus agreed that prompt removal of the functionality
was the right thing to do.
This occurred despite the fact we had a feature deprecation policy
for XFS long before that incident occurred - we just had not been
applying it to dusty corners of the user API we inherited from Irix.
It has been used for things like proc/sysfs knobs and mount options
that are no longer supported, and the lesson we learn is that is
should be applied to user APIs as well. We'd already extended that
process for deprecation and removal of support for on-disk formats
(i.e. the V4 format) but not legacy user APIS.
W.r.t to the V4 format deprecation, the kernel issues warnings
at mount time right now to say that the v4 format is deprecated and
will be going away.
XFS (dm-0): Deprecated V4 format (crc=0) will not be supported after September 2030.
XFS (dm-0): Mounting V4 Filesystem
XFS (dm-0): Ending clean mount
xfs filesystem being mounted at /mnt/scratch supports timestamps until 2038 (0x7fffffff)
mkfs.xfs warns if you explicitly make a v4 fielsystem:
# mkfs.xfs -N -m crc=0 /dev/mapper/fast
V4 filesystems are deprecated and will not be supported by future versions.
....
#
The timeframe for support is documented in both the mkfs.xfs man
page and the XFS section of the kernel admin guide published here:
https://docs.kernel.org/admin-guide/xfs.html#deprecation-of-v4-format
Indeed, if you keep reading down that link, you'll see all the
deprecated mount options, sysctls, etc and their removal schedule,
as well as all the removed options and when they were removed.
Deprecation and removal of old features is something that all long
term projects need to be able to perform, and the Linux kernel is no
different. Just because the Linux kernel project as a whole
doesn't have full software lifecycle management processes, it
doesn't mean that every kernel subsystems have no full software
lifecycle management processes.
Rather than saying "you cannot do X", it is better to learn why "we
*need* to do X" and then come up with a sane process for allowing X
to occur. The recent a.out removal and the reverted /dev/urandom
changes are good examples of how having a well thought out feature
deprecation and removal process is a really good thing to have.
Cheers,
Dave.
--
Dave Chinner
[email protected]