> > So from my distro experience installed userbase of reiserfs is pretty small > > and shrinking. We still do build reiserfs in openSUSE / SLES kernels but > > for enterprise offerings it is unsupported (for like 3-4 years) and the module > > is not in the default kernel rpm anymore. > > > > So clearly the filesystem is on the deprecation path, the question is > > whether it is far enough to remove it from the kernel completely. Maybe > > time to start deprecation by printing warnings when reiserfs gets mounted > > and then if nobody yells for year or two, we'll go ahead and remove it? > > Yup, I'd say we should deprecate it and add it to the removal > schedule. The less poorly tested legacy filesystem code we have to > maintain the better. > > Along those lines, I think we really need to be more aggressive > about deprecating and removing filesystems that cannot (or will not) > be made y2038k compliant in the new future. We're getting to close > to the point where long term distro and/or product development life > cycles will overlap with y2038k, so we should be thinking of > deprecating and removing such filesystems before they end up in > products that will still be in use in 15 years time. > > And just so everyone in the discussion is aware: XFS already has a > deprecation and removal schedule for the non-y2038k-compliant v4 > filesystem format. It's officially deprecated right now, we'll stop > building kernels with v4 support enabled by default in 2025, and > we're removing the code that supports the v4 format entirely in > 2030. Haha. It is not up to you. You can't remove feature people are using. Sorry. Talk to Linus about that. Best regards, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates.
Attachment:
signature.asc
Description: Digital signature
