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? -Eric
