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@xxxxxxxxxxxxx> 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
