On Fri, Sep 08, 2023 at 01:38:27AM -0700, Christoph Hellwig wrote: > 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. Yet that is exactly what we need. We need a well defined life-cycle policy for features like filesystems. Just as much as we need a clear, well defined process for removing obsolete filesystems, we need a well defined policy for merging new filesystems. The lack of well defined policies leads to arguments, arbitary roadblocks being dropped again and again in front of merges, and it does not prevent things like "dumping" from occurring. i.e. the filesystem is merged, and then the "maintainer" immediately goes AWOL and this new filesystem becomes an instant burden on the rest of the fs development community to the point where fs developers already immediately disregard any issue on a kernel that has used that filesystem. Without defined policies and processes to avoid repeating the same mistakes and arguments and disagreements over and over for each new filesystem someone wants to merge or remove, we aren't going to pull ourselves out of the hole we've dug. This isn't the wild west here; this is a room full of professional engineers. Defining new processes and policies to make things easier, take less resources, cause less friction, make operations more efficient, etc is part of what we are supposed to do. Not everything can be solved with code; the lack of defined processes for making major changes is the biggest single issue leading to the problems we have right now.... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
