When and why to deprecate filesystems

Removing support for old hardware is difficult enough, but there does often come a point where it becomes possible. If a particular device has been unavailable for years and nobody can point to one in operation, it may be time to remove the support from the kernel. Another strong sign is a complete lack of maintainer interest; that led to the recent decision to remove support for the NDS architecture, for example. Filesystems can be harder, though; they are independent of the hardware and can thus live far longer than any particular device type. Users can hold onto a familiar filesystem type for a long time after most of the world has moved on.

Reiserfs is certainly a case in point; this filesystem was first covered in LWN in 1999; it found its way into the 2.4.1 kernel the next year despite a fair amount of opposition based on the allegedly stable nature of 2.4 releases. There were a number of reasons for the inclusion of Reiserfs; chief among them, perhaps, was that it was the first Linux filesystem to support journaling. This filesystem attracted a fair amount of interest in its early days and some distributions adopted it as the default choice, but its own developers quickly moved on to other things; by 2004, Hans Reiser was arguing against enhancing Reiserfs, saying instead that his new Reiser4 filesystem should be adopted instead. In the end, Reiser4 was never merged, but Reiserfs lives on in the kernel.

Recently, Matthew Wilcox observed that maintenance of Reiserfs appears to have stopped. So he naturally wondered if there were still any active Reiserfs users, or whether perhaps the filesystem could be removed. Keeping it around has costs associated with it, after all, and it is getting in the way of some enhancements he would like to make.

As noted above, there is not normally a natural point where kernel developers can conclude that there is no value in keeping a filesystem implementation in the kernel. Reiserfs still works for any users still running it, and they would be within their rights to see its removal as causing just the sort of regression that the kernel community so loudly disallows. So the best that can usually be done is to place a prominent deprecation warning in the kernel itself and wait a few years; if opposition to the removal does not materialize during that time, it is probably safe to do. A patch adding that deprecation has been posted and seems likely to be merged for the 5.18 kernel release.

During the discussion, Byron Stanoszek did surface to confess his ongoing use of Reiserfs and desire to see it supported for a bit longer. Jan Kara responded by noting the limited nature of the support Reiserfs gets now:

Frankly the reality of reiserfs is that it gets practically no development time and little testing. Now this would not be a big problem on its own because what used to work should keep working but the rest of the common filesystem infrastructure keeps moving (e.g. with Matthew's page cache changes, new mount API, ...) and so it can happen that with a lack of testing & development reiserfs will break without us noticing. So I would not consider reiserfs a particularly safe choice these days and rather consider migration to some other filesystem.

Kara did offer to extend the deprecation period for Reiserfs, though, if it were really necessary.

As it happens, Stanoszek raised an issue that plays into the timing of the deprecation of Reiserfs, and highlights one of the issues associated with deprecation in general. Even the most dedicated users of Reiserfs will eventually find themselves wanting to move on because that filesystem has a year-2038 problem. In January of that year, the timestamps used within Reiserfs will overflow, leading to overall confusion. Since these timestamps are buried deeply within the on-disk filesystem format, they can't be fixed with a simple code tweak. Evacuating any data from Reiserfs filesystems before then seems like a prudent thing to do.

This might not seem like an urgent problem, since the deadline is over 15 years away. But there are reasons to take action now, which is why Dave Chinner asserted that the time had come to deprecate all filesystems that are not 2038-ready. He later explained in more detail:

With that in mind, this is why we've already deprecated non-y2038k compliant functionality in XFS so that enterprise kernels can mark it deprecated in their next major (N + 1) release which will be supported for 10 years. They can then remove that support it in the N+2 major release after that (which is probably at least 5 years down the track) so that the support window for non-compliant functionality does not run past y2038k.

The point is that deprecating a filesystem in the mainline kernel does not change the fact that it was included in recent long-term-support kernels. The 5.15 kernel will, if past patterns hold, be supported until 2028; it will have Reiserfs in it that whole time. As Wilcox pointed out, that serves as a sort of lifeline for users who cannot move away from the filesystem immediately, which may be a good thing. But it also poses an ongoing problem for developers charged with maintaining those kernels.

That is because supporting deprecated code in a long-term-stable kernel will be increasingly difficult. Ted Ts'o noted that maintainers of stable kernels will not be able to rely on upstream for fixes anymore, and any fixes that are made may not propagate to all kernels due to the lack of a central location for them. So doing high-quality maintenance of Reiserfs for six years, after it has been removed from the mainline, will be a challenge. Any enterprise kernels based on that stable release may include Reiserfs for longer than that. Enterprise distributors have to think in terms of supporting current kernel features for as long as 15 years; if they want to avoid the additional challenge of supporting year-2038-incapable filesystems after that date, the deprecation process needs to start now.

The implication is that we are likely to see other filesystem deprecations before too long. The NFSv3 protocol, for example, uses 32-bit time values and will break in 2038. The ext3 filesystem has similar problems; in this case, the data can be read as an ext4 filesystem, but the on-disk format simply cannot represent times correctly. So, like the XFSv4 on-disk format, which is also not year-2038 capable, ext3 needs to be migrated away from.

These deprecations will likely cause some unhappiness among users who have stuck with a working solution for years; switching to a new filesystem type can make people nervous. But the alternative is worse. Year 2038 provides a nice (and legitimate) excuse for developers to remove some old and unloved filesystems a bit more quickly than they might otherwise be able to. Once that passes, deciding when old filesystems should go will, once again, be a more difficult problem.