"Linux kernel developer Matthew Wilcox has proposed removing the ReiserFS filesystem from the Linux kernel – a relatively rare step."

https://www.theregister.com/2022/02/..._takes_a_step/

So I guess the kernel forum and general forum have not been relevant enough for these news.

I didn't mean to post here I request the post to be moved to Linux - News

A shame. I've used the ReiserFS since 2000, because I needed the stability of it knowing that because where I live, out in the sticks, brown-outs and black-outs and constant surges, etc, are common every day occurrences.

Using ext3/4 would be 'okay' for a few of these happenings, but eventually I would have a hard drive with nothing but a mess and I would have to either re-install or buy a new hard drive.

ReiserFS has saved my data and hard drives *innumerably* these past 22 years. I've *still* got 120GB hard drives sitting on shelves with dust on them that are >12 years old that I could pop into one of my current systems (14.2 or 15) and run that have survived this long *because* ReiserFS was the one file system that could handle the garbage of electrical problems we have in this area.

I find it depressing that Linux 'experts' are going the way of M$ and 'fixing what ain't broke'.

Even though I appreciate that its author ran into uncomfortable trouble with the Russian Mafia , I do think that "ReiserFS" is a very good system, especially for its efficient use of disk space in storing "hundreds of thousands of small files," which of course is the typical case. Therefore, I see no compelling reason to "remove it." Just leave it alone. You can use it, or not, as you want to.

If it is being maintained then technically no reason to remove it - I guess the issue is the name itself being associated with the former author - if thats the case, why not fork it then under some kind of new name? I don't know.

I guess the real question which should be addressed is: What should be done when (any) BDFL for some reason reaches EOL while 'intestate' i.e. without having appointed a successor?

It's going to be a problem, particularly as many BDFLs are not young any more. This case is particularly knotty as the name that identifies the project appears to stink, although the software doesn't.

Ideally, every BDFL will appoint someone and there will be no coups d'état. Meanwhile, back in the real world…
EDIT: As for the new name - SFS3 = Small File System v3?

Well in this case nobody really took up the mantle, so technically anyone who is maintaining the FS can perhaps be the next BDFL for this FS - not sure about the version 5 though as that has not been included in the kernel even prior to this....uh , controversy.. But someone was still maintaining that one too technically. So now it is a bigger mess, version 3 , nobody is the head of , but it is still in the kernel with said name v5 still not in kernel.

So who is going to appoint a BDFL for this filesystem - or can someone just take it over? Then when that is done, should it just be renamed? Since again the controversy is the name of the FS associated with the former creator - again, simple solution is just rename it to something else.

As it's in the kernel and this is what started it all, what about the kernel maintainer. The bigger question is who is going to urge all BDFLs to either appoint a number 2 or 'make a will'? That could be that every contributor with more than X commits in the last year appoints the new BDFL.

According to what I have read, the last updates/bugfixes to the system was in 2019. plus it is apparently causing compatibility issues with Matthew's page cache changes, new mount API etc. From the Linux kernel Mailing list: