On Thu, Sep 07, 2023 at 08:54:38AM +1000, Dave Chinner wrote: > There's a bigger policy question around that. > > I think that if we are going to have filesystems be "community > maintained" because they have no explicit maintainer, we need some > kind of standard policy to be applied. > > I'd argue that the filesystem needs, at minimum, a working mkfs and > fsck implementation, and that it is supported by fstests so anyone > changing core infrastructure can simply run fstests against the > filesystem to smoke test the infrastructure changes they are making. Yes, that's what I tried to imply above. We could relax fsck a bit (even if that is playing fast and lose), but without mkfs there is no way anyone can verify anything > > I'd suggest that syzbot coverage of such filesystems is not desired, > because nobody is going to be fixing problems related to on-disk > format verification. All we really care about is that a user can > read and write to the filesystem without trashing anything. Agreed. > I'd also suggest that we mark filesystem support state via fstype > flags rather than config options. That way we aren't reliant on > distros setting config options correctly to include/indicate the > state of the filesystem implementation. We could also use similar > flags for indicating deprecation and obsolete state (i.e. pending > removal) and have code in the high level mount path issue the > relevant warnings. Agreed. > This method of marking would also allow us to document and implement > a formal policy for removal of unmaintained and/or obsolete > filesystems without having to be dependent on distros juggling > config variables to allow users to continue using deprecated, broken > and/or obsolete filesystem implementations right up to the point > where they are removed from the kernel. I'd love to get there, but that might be a harder sell.
