ReiserFS has not been actively maintained for many years. It has been
marked as obsolete since Linux 6.6, and is scheduled for removal
in 2025. A warning is logged informing users of this every time a
ReiserFS file system is mounted. It suffers from unfixable issues
like the year 2038 problem.
JFS is a slightly more ambiguous case. It also has not been actively
maintained for years; even in 2008 questions were being raised
about its maintenance state and IBM’s commitment to it, and some
enterprise distributions were opting not to ship support for it as
a result. It will [indefinitely postpone journal writes], leading
to data loss over potentially arbitrary amounts of time. Kernel
developers [considered marking it as deprecated] last year, but
no concrete decision was made. There have been [occasional fixes]
to the code since then, but even the developer of much of those was
not opposed to deprecating it.
[considered marking it as deprecated]: https://lore.kernel.org/lkml/Y8DvK281ii6yPRcW@infradead.org/
[indefinitely postpone journal writes]: https://www.usenix.org/legacy/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf
[occasional fixes]: https://www.phoronix.com/news/JFS-Linux-6.7-Improvements
Regardless of whether JFS should be removed from the kernel, with all
the implications for existing installations that entails, I think
it’s safe to say that no new Linux installation should be using
either of these file systems, and that it’s a waste of space and
potential footgun to be shipping support for them on our standard
installation media. We’re lagging behind other distributions on
this decision; neither is supported by Fedora’s installation media.
(It also just so happens that `jfsutils` is the one remaining package
in the minimal installer ISO that has reproducibility issues, due to
some cursed toolchain bug, but I’m not trying to Goodhart’s law
this or anything. I just think we shouldn’t be shipping it anyway.)
Otherwise we get a clash when generating the initrd since the initrd tmpfiles
options create a symlink at /etc/tmpfiles.d/ and any subsequent writes inside
this directory because of initrd.systemd.contents will cause a permission denied
error.
