All that said, if it's hurting kernel development and almost nobody is using it, perhaps a deprecation cycle is due. Maybe bcachefs is a good replacement? Or perhaps nobody cares about efficiently storing small files these days at all, and we just all go to XFS, ext4, and ZFS. I think dropping it during a short period is detrimental to users. Maybe a two or three version warning is due.

I have a filesystem with an absurd number of tiny files in it. I host a statically rendered wikipedia mirror. Tens of millions of gzipped html-files with a filesize in the range 1-5 Kb.

ReiserFS is the only filesystem I know that deals even the slightest bit gracefully with this thanks to tail-packing.

Ah, but that's all I can think about when I read about reiserfs. For anyone who is unaware, the author, Hans Reiser, killed his wife and hid her body. There was a long and public investigation and he was found guilty. He later produced her body as part of a plea deal.

Data loss bugs sure sound exciting, but I'm old, and stable, and I prefer my file systems like myself.

Admittedly, it's not a great signal if the candidate hadn't heard of it or used it depending on their career length because plenty avoided it and happily lived in other FS worlds or avoided certain hype, but it's a fairly good positive signal if someone actually starts talking about it knowledgably in some way regardless of it on positive or critical notes--just have to keep survivorship and confirmation biases actively in mind when weighing these things.

I appreciate the ability to shrink/grow an existing ReiserFS, which I do often enough as I add new storage to my LVM layouts.

I have never lost a ReiserFS filesystem due to corruption, so the tooling seems sufficient for me.

I hope it stays in the kernel for a long time.

When I started in Linux full-time, back in the early 2000s, I was presented with different fs options - the installer did not give me any information on benefits, or on which ones were considered "stable". ext2 was available, but it also had a built-in version number, and I feared that once ext3 eventually rolled over, it might be incompatible. So I chose the fs that came with a name attached: ReiserFS. If someone was willing to attach their name to their code, I figured, that must be some quality code.

ReiserFS served me well, even though it always was a system lurking in the background. I was not a storage specialist. I was just a guy doing work on a Linux desktop, and ReiserFS "just worked". Occassionally, I put in a new disk, and watched the progression of other fs. Eventually, I switched over to ReiserFSv4.

Fast forward a few years, and the whole murder thing happens. Immediately the thing that made ReiserFS stand out for me becomes radioactive - the name is burnt. And I see distros slowly phasing out advertising the option of having a ReiserFS partition. Yes, it was still there when you searched for it, but it didn't feature prominently in the installers anymore. And it is obvious that the code becomes stale - arguably understandable, who would do OSS work on code that is branded the name of a murderer?

Twenty years later, I am still a Linux user. The last ReiserFS disk got shredded a year ago. Feels like the end of an era.

Lessons learned: Naming matters. If you attach your name to something and want that project to survive, maybe do not commit violent crimes.

The incident was really eye-opening in how fragile was my data: if .so files were not affected, I would have continued to use the system and erroneous data would silently be propagated to backups.

Does there have to be explicit kernel-level support to support a filesystem? Even if they remove support, does that stop anyone from releasing a kernel module and supporting it?

I think some of the published cases where userspace would have been "broken" and Linus got angry were fairly minor, as in you might not even need to fix the software, the user just has to be aware of different defaults. Whereas updating a kernel to a version where the filesystem is not supported will definitely render the installation unusable.

If paragon can get their cribbed together ntfs driver included in mainline then why can't reiser4 get merged?

Past HN thread: https://news.ycombinator.com/item?id=2131221

https://lkml.org/lkml/2012/12/23/75

I was surprised to see that Linux has in fact removed other filesystems in the past (and I had to look up the word "senescent").

So the real news to me here is that a somewhat "major" break in userspace is being considered.

Sure, ReiserFS might not be getting a lot of new installs, but the fact that people have submitted fixes to it within the past few years means it has some. There are installs of it out there. Wilcox is considering breaking userspace for some users.

Linux is famous, famous for keeping backwards compatibility for almost everything forever. The stories of Linux backwards compat are up there with stories of Windows still supporting AUX and CON and other special file names. Is "WE DO NOT BREAK USERSPACE" still worthy enough to be shouted at the top of your email lungs?

The systems were hosting map tiles of the entire Earth, and a lot of them were solid blue (ocean) or solid beige (unoccupied land). Those files were something like 60-300 bytes, going from memory. Reiser was basically the only FS that would handle that reasonably.

Have you ever tried Kiwix (https://www.kiwix.org ) and looked at the ZIM format (https://en.wikipedia.org/wiki/ZIM_(file_format) ), in particular those for Wikipedia (https://download.kiwix.org/zim ) ?

> ReiserFS is the only filesystem I know that deals even the slightest bit gracefully with this thanks to tail-packing.

Are there any newer file systems that cope with this use-case?

[1]: https://web.archive.org/web/20060318185107fw_/http://www.nam...

FWIW at some point it also had quite severe stability issues. I'm sure those were solved but that might have contributed to the fact why there was no effort to fork it but instead people went with ZFS, XFS and eventually ext4

It's like asking about Pamela Jones, from Groklaw, and her red dress. Fun trivia, but it tells you nothing about a person's current technical skills (or even their past ones!), just their ability to remember random names/facts, and excludes newer/younger staff.

Back then reiserfs was too new, and therefore not something I'd consider deploying to production systems. These days? Obsolete in practice. So I guess there would be many like me who have a vague memory that it was gonna be cool, with plugins and stuff, but who never actually used it or tried it.

(Maybe it's different if you're interviewing/grilling somebody for a very FS/Storage-heavy NAS-producing company, but there I'd expect conservatism to be highly appreciated?)

I'm not entirely sure what's gained by asking a candidate about FAT16.

The issue as I remember is that ReiserFS was developed as a commercial product by Reiser's company, and after the trial started it fell apart, and with that the original developers had to find new jobs.

It's possible the commercial nature discouraged third party contributions -- who wants to effectively be an unpaid employee?

It also was rather troublesome with frequent stories of corruption, and at that time they were working on ReiserFS v4, which meant that anybody interested in filesystem guts was probably waiting for the next version to show up, rather than spending time on a very complex piece of code that was about to become obsolete. Kind of the same problem that Perl suffered from.

And after all was said and done, ReiserFS 4 was still incomplete and extremely experimental. The list of people looking to polish up a very complex piece of software without the original team's assistance couldn't have been very large.

I think all these things added up together and quickly finished it off.

I formed the impression that Hans Reiser's somewhat bombastic approach did not interface well with kernel development anyhow when Reiser 4 came out. I remember reading some rather strange discussion threads at the time, including a - perhaps tongue-in-cheek - suggestion that Linux use Reiser 4 as its VFS and implement all other filesystems as plugins to it.

At one point, employees of his company were continuing to develop Reiser 4 (which they'd been working on for some time) and try to get it merged, even after the original author was no longer able to work on it. I presume those efforts were eventually dropped, which is very understandable but sad for the other developers.

Oh, I don't know, the Linux maintainers who have related to the software rationally and sensibly since Reisers' incarceration?

Silly and lofty "lesson".

I mean, yes, your filesystem becomes inaccessible, but any programs that you could run if you could access that filesystem by some other means would still function. None of them depend on ReiserFS specifically for their function.

Userspace breakage is more about changing interfaces in such a way that applications using that interface change their behaviour somehow. This does not apply to removed drivers.

AFAIK, BTRFS has everything Reiser has with a far better maintenance and ongoing feature expansion.

Really, the only reason to use reiser at this point is because you are dealing with data that you can't, for some reason, move to a new filesystem yet you still want to have updates to the kernel.