lkml.org 
[lkml]   [2022]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Is it time to remove reiserfs?
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

\
 
 \ /
  Last update: 2022-02-23 16:29    [W:0.170 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site