Re: [MAINTAINERS/KERNEL SUMMIT] Trust and maintenance of file systems

[Guenter Roeck <linux@roeck-us.net>]

On 9/13/23 09:43, Eric Sandeen wrote:
> On 9/7/23 6:18 AM, Steven Rostedt wrote:
>> On Thu, 7 Sep 2023 13:38:40 +1000
>> Dave Chinner <david@fromorbit.com> wrote:
>>
>>> Hence, IMO, gutting a filesystem implementation to just support
>>> read-only behaviour "to prolong it's support life" actually makes
>>> things worse from a maintenance and testing persepective, not
>>> better....
>>
>>  From your other email about 10 years support, you could first set a fs to
>> read-only, and then after so long (I'm not sure 10 years is really
>> necessary), then remove it.
>>
>> That is, make it the stage before removal. If no one complains about it
>> being read-only after several years, then it's highly likely that no one is
>> using it. If someone does complain, you can tell them to either maintain
>> it, or start moving all their data to another fs.
>>
>> For testing, you could even have an #ifdef that needs to be manually
>> changed (not a config option) to make it writable.
> 
> This still sounds to me like /more/ work for developers and testers that
> may interact with the almost-dead filesystems, not less...
> 
> I agree w/ Dave here that moving almost-dead filesystems to RO-only
> doesn't help solve the problem.
> 
> (and back to syzbot, it doesn't care one bit if $FOO-fs is readonly in
> the kernel, it can still happily break the fs and the kernel along with it.)
> 
> Forcing readonly might make users squawk or speak up on the way to
> possible deprecation, but then what? I don't think it reduces the
> maintenance burden in any real way.
> 
> Isn't it more typical to mark something as on its way to deprecation in
> Kconfig and/or a printk?
> 

I think that commit eb103a51640e ("reiserfs: Deprecate reiserfs") is a perfect
and excellent example for how to do this.

Guenter