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'm not sure btrfs is a sane replacement, though. It's exceedingly complex, and I try to avoid needless complexity where possible.
For example, I have a /data drive formated xfs, then I mount a /backup formated btrfs, rsync the 2, take a btrfs snapshot, and unmount /backup.
https://btrfs.wiki.kernel.org/index.php/Production_Users
Facebook deployed it on millions of servers. Is that production enough? Synology NAS devices also use it.
I've heard RAID 1 and RAID 10 modes are safer, but after the FS corrupted my data I haven't really had a lot of trust in it or the people who say again that it's ready for serious use.
The advantage of having the creator, designer, and lead maintainer available among free society is definitely real. Regardless of the murder - even if we can separate the man's technical work from the rest of his life activities - he's not doing a lot of work on his creation while he's in custody. He's certainly not going to be furloughed to hackathons or conferences from a murder sentence.
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.
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?
https://encyclopedia.marginalia.nu/
The data is a bit stale right now, since there's a new dump available and I haven't converted it yet. But it's pretty easy to set up. Just grab a zim-file from here[1] and unpack with an appropriate library with an optional step of parsing and transforming the DOM then save into gzipped html files and set up a server for unpacking and serving those.
The conversion job takes a few days but it's not that bad.
[1] http://wikimedia.bytemark.co.uk/ (use a mirror if it doesn't work)
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.
[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
Sometimes we have no choice as to whether or not we can use the work of someone who has done bad things - Einstein was quite awful to his wife, for example, but it's not practical to ditch relativity just because he sucked on a personal level. But there's plenty of replacement filesystems - should there be no discussion as to whether or not we should weigh the moral issues alongside the technical ones?
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.
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.
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 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.
There also was weird artwork to go with all of that:
http://web.archive.org/web/20070219175315/http://www.namesys...
Add to that some people sometimes decide to give a famouse surname as a firstname for their kids. There is a non negligible number of people sporting the Lafayette, Napoleon, Lincoln as first name for example that could do something bad anytime.
Oh, I don't know, the Linux maintainers who have related to the software rationally and sensibly since Reisers' incarceration?
Silly and lofty "lesson".
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.
- someone posts a patch to enable refactoring which reiserfs code was blocking
- discussion goes into a deprecation plan, with someone suggesting reiserfs deprecation follow the same as xfs v4. These have formats have year 2038 bugs. Slated for code to be removed come 2030 by starting now
There is pretty much no way to allow people to 'volunteer' to do this kind of work without giving someone an incentive to get as many people into prison and using it as a giant slave work camp.
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?
Your kernel has to have compiled-in support for the filesystem of the drive you store your kernel modules on.
Thats how people boot from ZFS
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.
In some technical sense, the filesystem is just an implementation detail of the kernel for things like 'read', 'write', and 'mmap'. Since this is an implementation detail, it can be considered 'not part of the public API of the kernel'.
Put differently, the promise not to break userspace is aimed at developers and not at actual users. The case of changing defaults is then a problem of developers because their programs are all of a sudden behaving differently.
In userspace, I run "mount -t reiserfs ....", and it mounts a filesystem. If the kernel deletes the reiserfs code, the userspace mount command / kernel 'mount' syscall will fail.
That seems like a very clear userspace thing that breaks.
Is there a reason that the mount syscall no longer accepting a previously valid argument isn't a userspace breaking change?
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
I don't know anything about it and whether other contributors are able to give as much input as he could but judging by the comments of unfixed bugs and few commits, it would sound like it is a big risk of stagnation. No?
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?
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.
