On Thu, Sep 07, 2023 at 07:53:36AM +0700, Bagas Sanjaya 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. > > OK. > > > > > 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. > > > > 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. > > Something like xfs v4 format? Kind of, but that's a story of obsolescence, not a lack of maintenance. For those that don't know the back story, it's below. For those that do, skip the bit between the '----' lines. ---- We deprecated the v4 XFS on-disk format back in 2020 because it was superceded by the v5 format that was merged in 2013 (a decade ago). Since then we have not been adding features to the v4 format because the v5 format fixes a heap of problems with that old format that can't otherwise be fixed without changing the on-disk v4 format to something like the V5 format. Now throw in the fact that the v4 format is not y2038 compliant. It's got a hard "end of life" date without putting resources and effort into an on-disk format change. We aren't going to do that largely because the V4 format is a development dead end. Because the v4 format has a hard end of life date, we needed to have a deprecation plan for the format that was sympathetic to enterprise distro feature removal policies. Given that there's usually a 10 year support life from first release in an enterprise kernel, and typically a 2-3 year lead in cycle, we're looking at need to have filesystem feature removal occur 10-15 years before the hard end of support date. Further, feature removal policies required us to mark the feature deprecated for an entire major before we can remove it in the subsequent release. This means we needed to make a decision about the V4 format in 2020, a full 18 years before the hard end of life actually occurs. [ How many people reading this are thinking about what impact a decision made has on people using that functionality in 10 years time? This is something filesystem developers have to do all the time, because the current on-disk format is almost certainly going to be in use in 10 years time....] So we deprecated the v4 format upstream, and the enterprise kernels inherited that in 2020 before the major release went out the door. That means we can remove support in the next major release, and the upstream deprecation schedule reflects this - we're turning off v4 support by default in 2025... We don't want to carry v4 support code forever, so we have a removal date defined as well. All upstream support for the v4 format will stop in 2030, and we will remove the relevant code at that point in time. Long story short, we recognised that we have obsolete functionality that we cannot support forever, and we defined and documented the long term EOL process for to removing support of the obsolete functionality from the filesystem. This, however, does not mean the V4 code is unmaintained or untested; while it is supported it will be tested, though at a lesser priority than the v5 format code we want everyone to be using. THe V4 and V5 formats and code share huge amounts of commonality, so even when we are testing V5 formats we are exercising almost all the same code that the V4 format uses.... ----- It should be clear at this point that we cannot equate a well planned removal of obsolescent functionality from a maintained filesystem with the current situation of kernel being full of unmaintained filesystem code. The two cases are clearly at opposite ends of spectrum. However, we should have similar policies to deal with both situations. If the filesystem is unmaintained and/or obsolete, we should have a defined policy and process that leads to it being either "community maintained" for some period of time and/or deprecated and removed from the code base. Look at reiserfs. The maintainer stepped back and said "I'm happy just to remove the code from the kernel". It has been unmaintained since. Rather than pulling the rug out from under any remaining users, we've marked the filesystem as deprecated (and now obsolete) and documented a planned removal schedule. This is the sort of process we need to discuss, formalise and document - how we go about removing kernel features that are no longer maintained but may still have a small number of long tail users with the minimum of disruption to everyone.... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
