Personally I've always really liked ReiserFS. The collected storage of small files, the storage of the tails of files, the balanced tree structure, and the fast journaling gave better performance in reads, writes, boot time, and storage efficiency than most file systems. The focus on small files, which were and arguably still are most files on a typical system, was a big key to this. It made it ideal for storing things like configuration files, email in maildir format, email spools, version control repositories, source directories, and many executables. The logical successor was supposed to be btrfs, but that project IMHO may never be ready for production use.
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.
It's great for small files, but it's also got some really nasty little corner cases. You do not store ReiserFS filesystem images on ReiserFS filesystems without encryption, or the next time you run fsck, you'll end up with the two filesystems oddly merged into something entirely useless. I'm not sure if that's been fixed, I got a bit tired of the exotica for general daily driver systems, and ext3/ext4 cover my needs well enough.
I'm not sure btrfs is a sane replacement, though. It's exceedingly complex, and I try to avoid needless complexity where possible.
That's one heck of an edge case! How does fsck manage to completely confuse filesystem metadata and data like this? Surely this is only if there's corruption in the (outer) filesystem, right?
I think it was the --rebuild-tree argument, which as I understand tries to fix an otherwise completely broken filesystem by searching for anything that looks like metadata and gluing it back together.
I've not looked at reiserfs in many years though, so I could be mis-remembering here.
Seems like something pretty fixable too... Only scan areas of the disk which aren't part of already valid filesystem structures, including the users files.
It's kind of the point of fsck that it scans areas of the disk which aren't part of already valid filesystem structures. It's what you run when your filesystem structure is invalid in order to recover as much as you can.
No, the meta-data is somehow distributed and fsck can pick up pieces of it. I don't think you have to encrypt the image to avoid the edge case, a compress of the image should be enough. It still sucks though.
Many other filesystems have one or more arrays for metadata. Sometimes these are formatted like files themselves. So a tool to recover it only has to guess at those contiguous arrays, instead of considering essentially any block metadata.
Yeah... especially if you tend to back up systems when you're rebuilding or replacing them by just backing up the whole disk. It's got everything, you can mount it as a loop device (which you can't do with a compressed image as someone else mentions), etc. I've got a lot of random filesystem images around, and once I trashed a fs entirely with Reiser images on Reiser, I was done with it.
I feel like you really need to have a reason to use ext3/4. I stick to xfs for daily stuff and btrfs if I want any sort of extra functionality. It's super stable in basic configs.
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.
xfs dynamically allocates inode storage space. A very typical failure scenario of ext4 is to run out of inode quota while there are plenty of free blocks available. This scenario is not possible with xfs. This alone makes it more dependable than ext4 in practice.
There used to be major performance variances where xfs was better in certain workloads and ext4 in others, but those appear to have been smoothed out and now their performance seems very similar across all workloads.
> 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.
I also unmount the backup drive(s) when not in use, but I'm just cp'ing the important directories from one ext4 filesystem to another. I'd consider btrfs or xfs for general use, I'd love to know why you choose xfs for everyday use. Sure, it's better than ext4, but why not btrfs all around?
I once formatted an external drive with xfs, wanted to repurpose some of the space to be readable on Windows, found out you couldn't resize xfs, reformatted the drive as exfat (lol you can't resize that either), and lost my last copy of some past files.
From the same standpoint, btrfs is not sane either. You cannot dd it to a different block device, even when unmounted. When the kernel sees two btrfs filesystems with the same UUID on two different block devices, it thinks they are one filesystem, and corrupts both.
The difference is that you can easily edit the UUID of a btrfs filesystem with `btrfstune -U` immediately after making the copy so the filesystems are unique again. You need to do this anyway if you have mount rules based on the UUID, regardless of the filesystem type, or you run the risk of mounting the wrong device. It is also possible to tell btrfs which devices make up a particular filesystem with the device= mount option, which ought to bypass the default grouping based on the UUID.
Can one wait indefinitely before running `btrfstune -U`? The "immediately" in your comment makes it sound like a racy/flaky workaround, assuming you are referring to immediacy in time.
You can wait until just before the next time the device is scanned for filesystems, or perhaps when the next btrfs filesystem is mounted. Beyond that it will start to cause problems.
Facebook doesn’t use it’s servers the same way we use our computers. They image machines in and out of existence. They don’t have file systems going through power loss on a weekly basis. They don’t upgrade the kernel on existing installations. They don’t expand their storage after the fact. If their machines fail, they don’t care - they’re completely fungible.
> Every FS corruption and weird behavior is put aside and investigated. They very much do care.
Just because you and I are using different meanings of the word "care" doesn't mean the point isn't valid. They "care" in that they would like to know what went wrong and study it further. They don't "care" in the sense that they suffered no real harm and no stakes were riding on any one particular server that failed. It's not just a matter of having a backup/redundancy, it's about having automated systems (or even just standard procedures that are being executed on a daily basis at that scale one way or the other) that take care of these failures. So even in production, "regular" btrfs users might have backups so "no lasting damage" would be incurred, but that's hardly the same as openly volunteering themselves for risk.
That's all besides the main point: Facebook is deploying "known good" configurations. They're using a very select subset of features. They're not trusting changed btrfs features/implementations being correct or, as was my experience, worrying about less-used/tested codepaths leading to data loss.
“Also keep in mind we pay really close attention to burn rates for our drives,
because obviously at our scale it translates to millions of dollars. Btrfs has
improved our burn rates with the compression, as the write amplification goes
drastically down, thus extending the life of the drives.”
As with anything it comes down to money. Yes a machine going down doesn’t impact the cluster but it does impact their wallet. Every failure of a disk costs money and on the scale of the big boys that can add up to big money.
So while “the system” doesn’t care about drive failures the accountants and CFO’s absolutely care.
Just pointing out that "caring about physical drive failure" and "caring about disk corruption or data loss" are completely independent and the latter does not directly equate big money (as there are already systems and SOP in place to deal with handling failed servers). Btrfs isn't notorious for actually frying disks, just the data on them.
Do they care about the FS just silently eating data? I ask because btrfs has been known to do that. Sure, you're not replacing the drive, but you're probably wiping the VM's disk image and creating a new one.
The thing of recreating VMs a lot instead of upgrading or keeping them a long time is production use. The whole point of VMs, aside from not taking 3 months to order and provision, is that you can put the "long-term maintenance of a disk and OS" cost to zero and just recreate from SoR (hopefully git) whenever something needs to change. If you are editing state on persistent VMs, you are missing some really nice features of VM based deployment. It's like containers but more well understood and possibly more cost efficient (depending on the code).
Lots of people seem to turn up their nose at btrfs. Is there a reason for that? Was it perhaps launched before it was really ready and people still remember early versions?
I can give you mine. I was working with a Raspberry Pi 3, and using a USB SSD. It's a USB2 link, so a bit choked, and I figured, hey, filesystem compression can help here, btrfs supports it, great! And it helped - you could get "real world" disk reads a good bit faster than the USB2 bus speed.
Until one day, I rebooted, and it didn't come back up. Analysis on another system was that the btrfs filesystem was just... toast. I've no idea what happened, I found some stuff that said "Oh, uh... don't use btrfs over USB, it kinda breaks in some cases...", the recovery tools couldn't even decide that the filesystem was a btrfs filesystem, and, nope.
I put data on the filesystem, I expect it to come back. btrfs broke that guarantee with a Pi full of data (nothing too important, they're just scratch systems and light desktops), so... I now stick to the boring things like ext4 that have been exceedingly well proven. Is it the best filesystem out there in terms of features? Certainly not. Am I pretty darn sure that I'm not going to trip some edge case and totally scramble the filesystem? Yes, and that's what I care about.
Lots of us got burnt with data loss and aren’t willing to give it a chance again. Maybe it’s better now? I don’t have a reason to give it a second chance when there are plenty of stable alternatives that have saved my ass I’m the past instead of telling me I’m SOL.
That's exactly it. I've used btrfs in production since Ubuntu 10.04, at scale since 12.04, and had nothing but great experiences with it - especially with the seed volume functionality, which allowed me to build the foundation for a major container-as-a-service platform before Docker was a thing. btrfs never lost our data, but I've also seen way too many btrfs kernel panics that were clearly related to insufficiently mature filesystem code, and I can understand people who did lose data, got burned and never want to trust btrfs again.
For me, it was https://bugzilla.kernel.org/show_bug.cgi?id=85581. Yes this endless-write loop is long fixed, but, given that something with 99% similar symptoms has surfaced in kernel 5.16 (or was this original bug not fixed properly?), I would say no.
It is a complex beast. It needs some maintenance and performance will degrade without it.
I've never lost data to it, I've never tried the soft RAID modes it has though, but I've experienced it making a system almost unusably slow. SUSE out of the box with it automates a lot of it and it's pretty remarkable. Transactional mode if you want it seems like a game changer for some servers and the snapper stuff has saved my bacon a couple times. It's getting there but like I said, it needs some maintenance and just formatting a partition with it is likely the wrong way to experience it.
For me, when I tried btrfs (which was about 10 years ago now) I discovered it was extremely slow. And not like 50% slower—when I switched to ext4 or xfs on the same disk with the same data I was getting a 10x or so speedup.
AFAIK it's not so bad in single-device use-cases. I think most of the more recent failures I've heard about have all had to do with Btrfs RAID. The prevailing wisdom still seems to be that if you want to use RAID, use an md soft-RAID device or LVM under your single-device Btrfs filesystem.
RAID, especially 5 or 6 was my main concern, yes. If I'm using hardware RAID or a soft RAID under the FS, much of the promised benefit of btrfs is gone anyway. I can add to storage pools with ZFS or expand an LVM set, too, but what does using btrfs on top of anything buy me that ZFS, bcachefs, or something like f2fs does not?
> but what does using btrfs on top of anything buy me that ZFS, bcachefs, or something like f2fs does not?
Well, inclusion in mainline kernels is the big one over ZFS and bcachefs, I guess.
I haven't seen F2FS before, so I'm commenting on the basis of 30 seconds of Googling, here, but it doesn't look like it supports either copy-on-write or snapshots, which are the big selling points I've heard for continuing to use Btrfs on top of a device manager.
All problems are edge cases, to some degree or another. The only real question is how far out those edges are, and whether users are likely to bump into them.
Edge cases like Raid5/6 which had the write hole issue approximately a decade after btrfs was released. At some point you say "This filesystem has lost so much of my data that I will never return to it."
Burn me once, shame on you, burn me twice, shame on me. If you purchased a new ford and that car fell apart a week later, would you ever buy a ford again? Some will, most wont.
A better analogy would be if the car got you in an accident. I don’t care if something breaks quickly as long as that means it can be returned or replaced.
I agree, I love BTRFS and have used it for ages, including some small scale production systems. But I know it still has some edge cases as you mention, which made me wonder: what is the impediment to having those cases fixed? BTRFS has been around long enough and even has some decent commercial support from a few vendors, so it seems like we can't just discount it as "it's open source and nobody is motivated to fix those long tail problems." Is there some kind of design issue that makes them hard?
edit: sorry, cheap shot at Facebook. I have no idea why BTRFS edge cases are not being fixed.
What I do know is that ZFS recently released a feature specifically for the hobbyist/frugal community. The feature allows you to grow an existing RAID array, something a financially sound business would never do. So no customer of anyone supporting ZFS would ever use this, and it took significant effort of ZFS developers to implement this. Not to mention that introducing feature potentially introduces weird behaviour in ZFS that might endanger its (reputation of) stability.
I'm super happy with it, (as my company was not in fact financially sound when we invested in our on-premise storage hardware), but if I was CEO of ZFS I'm not sure I'd sign off on it.
Point was the post is about losing reiserfs, and people are presenting virtues of zfs and btrfs as reasons why we don't need reiserfs any more, and this virtue of zfs is unremarkable.
That is very informative about the edge cases for btrfs. My question was what are the edge cases in the other filesystems which put them on a level playing field with btrfs considersing it still has so many.
Are they using the RAID 5 or RAID 6 code in it? Because that was declared unfit for use well after we were all advised their filesystem was ready for prime time. Then it corrupted and lost data in situations that other file systems did not.
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.
I'm no big company, but I've been using btrfs on my Raspberry Pi file server and its disk has been sitting there spinning for something like 8 years with no issues yet. I keep hearing that "btrfs isn't production-ready" but I wouldn't know it from experience.
Perhaps you never lost data from it years after it was billed as ready for use, but many people did. I've never lost data on Reiser3 or Reiser4. I've not used bcachefs or f2fs much yet, but I've never lost data on those either.
Hear, hear on replacing reiserfs with bcachefs. Kent Overstreet could use the support, the project looks good, and to my knowledge he is not a murderer.
The salacious details are always part of this discussion and outside of a very carefully scoped conversation like was requested on the list I think that's always going to happen. On just a technical basis, though, I think bcachefs pays a lot of attention to many of the same issues ReiserFS does, gets more current maintenance, and is maintained more along the lines of kernel interfaces other filesystems use. That last one is the strongest point made in the email to the list.
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.
Hans' personality got in the way of technical work in more than one way; Reiser4 never got upstreamed partly (if not mostly) because he had too big of a chip on his shoulder to make the changes requested from upstream.
ReiserFS does have its benefits in highly specific use-cases.
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.
It's always been. I used it on my servers in "Raid 10" mode and on my daily driver for 3 years now.
As long as you don't do BTRFS-level raid 5/6. (Just do lvm-level or md-raid-level raid 5/6) don't do many subvolume with quota. (many subvolumes is fine) It's production ready.
I don't know where this "btrfs is not stable" coming from. According to HackerNews, I should have lost my data due to BTRFS 10 times already.
Okay, was it "not stable" because they expected it to be ext3-like and when btrfs discovered that their system eats bytes and refuses to mount (and they would need to use the recovery mode, get a second disk and do a copy and then a proper restore) or it was not stable because they ran into a kernel oops/bug/deadlock/etc?
Try the web server Redbean. You put it all in a single zip file, serving a file simply copies the pre-gzipped content directly into a tcp stream. Obviously some of the FS read performance cost is moved into navigating the zip file, but the storage overhead is not, and nor is the read+write-able nature of the FS.
Yeah. Tens of millions sounds fine. And you don’t have to keep navigating the raw zip file, you just do it once. “All file offsets available in a single immutable in-memory hash map” is basically the dream scenario. I imagine if you were desperate you could pack more in by representing your file names efficiently in memory, a bit of path compression or a trie or whatever, but if it already works it already works.
Years ago this was very similar to our use case, only much smaller file sizes, and Reiser saved an amazing amount of overhead.
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.
Oh I have a repository of tens of millions of small json files, and xfs chokes on that specific partition it's amazing. 5 minutes for a ls in the root folder (with only 2 folders). Tried moving it disk to disk in case I was on a broken disk, but no.
Indeed, I had a partition with a huge number of small files in the ext3 era, and reiserfs was the only one even remotely able to perform decently. I stumbled upon it last week and was happy and surprised to see that reiserfs was not removed.
We had millions of users of a mail service with everything stored in Maildirs. Reiserfs handled it fantastically on hardware ridiculously slow by modern standards. But I've not used it for maybe 15 years...
In my experience, integration with products is not really that hard. I've used sqlite3 bindings in half a dozen languages over the years, and they are generally fairly robust.
I literally discovered this just the other day, the whole concept is extremely intriguing but it hasn't been updated in some time (I'm guessing some forks have been though).
Relatedly, it would be pretty cool to be able to build your own filesystem features as layers on each other (such as block-level compression or encryption, block-level forward-error correction, cache promote, striping or other redundancy etc.). A modular FS with pluggable (but also upgradable) components and some sort of structured feature-flag schema metadata, and a way to migrate between variations (such as switching to a different compression or encryption algorithm).
Some of what you're describing is in ZFS. E.g., it has multiple compression algorithms; you can create many datasets -- each of these is either a ZFS filesystem or a volume which can have another FS deployed to it, but with compression and encryption handled by the "host" ZFS.
You may also be interested in FreeBSD's GEOM subsystem for storage.
But a special kind of database, that is usually bad with a lot of small entries, especially if they don't have a hierarchy (many files in one folder). Most SQL or NoSQL databases are much better at organizing small "files".
File systems aren't relational databases, but more like NoSQL half a lifetime before it was cool. They're typically backed by the same data structures and solve the same problems.
> 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.
Are there any newer file systems that cope with this use-case?
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.
> NB: Please don't discuss the personalities involved.
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.
It's unfortunate that ReiserFS is named after Hans Reiser; other people were working on it too (well before the murder, see e.g. [1] for a crude overview), and there's nothing stopping anyone from maintaining and developing it, no matter what Hans Reiser did. Yet in large part due to the name, it's strongly linked to him :-/ If Theodore Ts'o would have been convicted of murder the ext* filesystems probably would have lived on, as it's not "TsoFS".
I worked with Hans Reiser before he want off to Russia to found his company in Russia (we were at an EDA company, not on the same project but in the same small group). ReiserFS was very much his vision, the core ideas were his, so the names are appropriate. Most of those other people you mention were once his employees. He was very driven, and at first he struggled to explain his ideas. I didn't want to believe that he killed his wife, though I knew he was very troubled and tended to see people as tools.
I can still remember discussing the case while hanging around the student union office at school. I wanted to believe he didn't do it, in part because there would be a chance that the children might be reunited with their mother, and also because of a youthful naivety about the supposed honesty and integrity of someone of strong technical competence and achievement. I had been running reiserfs for years already by that point so I definitely had the "my team" bias. It's a sobering lesson that I continue to reflect upon to this day.
I feel like there's a small tautology here- who is most likely to name the software package after themselves? A narcissist, of course, and narcissism is a component of sociopathy.
So you also think Linus Torvalds is a narcissist ? And every people who name their project or company after their names are potential sociopaths ? What about all scientists who gave their names to the effects or law of physics (or math formulas) they discovered... ?
Linus didn't name Linux after himself, another person who distributed it named it after him.
Scientists also generally don't name their discoveries after themselves. The honor of getting someone named after yourself is something that your colleagues are supposed to bestow in recognition of achievements - sometimes long after the person in question is long dead.
That seems like overthinking things. I've named things after myself (and also other people), and I'm neither a narcissist nor sociopath. It just sounded nice.
Yeah that's also why I stopped using it. Why didn't they just fork it and change the name? I don't get it.
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
There is no need to over-analyze this. It's perfectly legitimate to feel that it's weird to use an FS created by someone who murdered his wife, or otherwise violated or opposed norms that you hold important. For instance, I certainly wouldn't use something called HitlerOS as my daily driver (or at all), no matter how good it was, because the name itself makes me uncomfortable.
Then i should not use a linux system because it contains code from NSA, Google, Facebook, Apple or even Microsoft. That's not a reason not to use a system. The US was more than happy to use things created by german war criminals ( V2).
If you care about those things very deeply, then perhaps that is exactly the right thing to do. Lots of people don't do things because of ideological or personal beliefs, even if it limits their options.
Many people use the BSDs for their transparency and despite Linux catching up in many areas, BSDs (which are arguably more political) have a rock solid reputation. (Maybe that's why all of Apple's flagship products are based on BSD - never heard of them using Linux though) IMHO people forget that software development is of course about the tech but really half of the work is about people, both in Opensource and Commercial developments. Large orgs think twice before they use a (perhaps free) software with bad reputation
There's no need to overreact about it either; no need to judge the book by its cover. To use your example, some people are having allergic reactions to the software as if it were named HitlerFS. The conflation is exaggerated. Dismissing great software because it was named after a man who would years later murder someone won't bring the victim back. It just eaves the world with less great software. Pointless and misguided moralism.
As I pointed out, this is not moralism. Humans aren't cold, calculating logic machines. We have emotions, and we care about our social standing.
If I choose to use a slightly inferor alternative because the name makes me uncomfortable, that is perfectly legitimate.
If using ReiserFS costs me a number of weirdness tokens (like using it in a workplace, and the relevant decision makers are likely to know about the murder now or in the future), then I may choose not to use it to conserve those tokens for other controversial initiatives that I care about even more.
Neither of those decisions may be "rational", but it's also not moralising. I simply have to take a complicated social/emotional calculus into account, something that most do unconsciously 24/7 without thinking "hmm, today I shall get on my moral high horse and decide that this is moral and the other thing isn't".
Props to you for pulling out the quote were he specifically said to not talk about that, and keep discussion about the APIs, proving that you read it, and then bring it into the thread anyway to derail it with the brutal murder topic.
HN is not the kernel mailing list, and the range of topics discussed on here are significantly wider than that of the mailing list. If we restricted ourselves to the same rules, there's not many posts on the front page that would be allowed.
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?
> There don't
seem to be any fixes for user-spotted bugs since 2019. Does reiserfs
still have a large install base that is just very happy with an old
stable filesystem? Or have all its users migrated to new and exciting
filesystems with active feature development?
Data loss bugs sure sound exciting, but I'm old, and stable, and I prefer my file systems like myself.
I don't know about you, but although I too am old and stable I have plenty of data-loss bugs, and I'm running on hardware that needs regular downtime and constant maintenance in order not to fail catastrophically. I therefore don't want my file systems too much like myself.
ReiserFS is a conversational litmus test I like to casually and indirectly name drop in technical interview discussions surrounding the world of Linux, file systems, and storage to fish and see if someone actually had been actively working in the domain circa 2000ish when there was a lot of hype and criticism bubbling surrounding performance with large sets of small files.
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.
Sadly, I don't think this is a good signal for anything anymore except being past a certain age and having been around Linux at the time. ReiserFS hasn't been relevant for fifteen years, as during its heydey it was quite unstable and after the incident development stopped completely. I say this as somebody who was in the storage industry in the early 2000s and worked with an engineer who personally knew Hans Reiser.
I can almost see that being useful, but at the same time I'd be more curious about the current knowledge somebody possessed than stuff from back in the day. It's also a bit of an (accidental?) age-test.
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?)
Absolutely. If you asked me to name current and historical filesystems on Linux I would 100% be able to name reiserfs - but features? Nope, not a single one. I was kinda surprised by the sibling comments that it has been THAT long. When it was actively in the news it was still unstable but promising. Then at some point it hadn't been mentioned anymore for a while and then we had ext4 and xfs and btrfs. So even as a linux user (and admin) I don't think it's anything anyone must know.
Is XFS stable ? I tried reiserfs, jfs and xfs at the beginning and stuck with jfs because reiserfs would eat a lot of processor power and xfs would not run fsck when the power got interrupted which resulted in a corrupted filesystem.
ReiserFS is my favourite Linux filesystem. I use it where most people just use the default ext4. I was originally attracted to it for the large-number-of-small-files support it had.
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.
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.
I don't think it's that big of a deal. If that was a big problem, but there was enough interest it would have just been renamed.
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.
It's interesting that, having avoided a filesystem with a version number, you eventually ended up on Reiser 4! Shows how much some branding decisions can affect with you acquire a user or not, since you then stuck with the "brand" (though I presume quite a lot of time had passed and circumstances may have been different).
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 were grandiose plans indeed! Including things like plugins, yes, and ideas like exposing metadata about files (like MP3 artist tags and such) in virtual files. You'd `cat song.mp3/artist` or some such, treating the file as a virtual directory.
There also was weird artwork to go with all of that:
I really liked the files-as-directories behaviour. One of the objections I recall from the time was that this sort of behaviour would make more sense at VFS level.
I'd love to have this sort of functionality available (ISTR it has potentially other useful properties - e.g. new properties / metadata attached to files can automagically be handled by things like tar).
My memory says that concerns around overlapping file and directory behaviour caused pushback here. I think being able to hardlink to a directory was the issue (if every file can be a directory then how do you avoid directory cycles) but I may be mangling the details.
Somewhat related, Minio now supports serving files from within ZIP archives. So that same song.mp3 could be accessed by opening the URL http://minio/files.zip/song.mp3. By treating the ZIP file as a virtual directory, you can access individual files within it without downloading the entire archive.
An Intel employee explained their code-naming on white-box server chassis/motherboard combinations back in the late 90s. There were chassis named things like "Balboa" and "Cabrillo". Motherboards were named things like "Buckeye", "Redwood", and "Sitka". He said "We've never been sued by a dead explorer or a tree."
No, now you'll get sued by people who are offended by one's choice in dead explorers — or even the use of explorers at all.
Imagine codenaming a chassis "Drake" today, where even the famed hotel in San Francisco changed its name (now it sounds like a generic chain hotel — "Beacon Grand").
Use Junipero Serra's name? Better hope your offices are vandalism-resistant...
Well in the case of last name unless those dead peoples was the last one standing with the surname there is always the possibility of a descendant or someone from a different branch of the family name tree commiting bad things.
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.
Well, it can work out OK if one particular person has a strong enough association with the name. Lincoln is a great example. It seems unlikely that anyone with that name will become so infamous as to tarnish it. The voters of Lincoln, Nebraska or the board of the Ford Motor Company (owners of the Lincoln automotive brand) are pretty safe from needing to rename those things.
There’s still the risk of a sudden culture shift where e.g. the San Francisco school board decides it’s no longer acceptable to have a high school named after Abraham Lincoln.
I'm serious. Are you going to fix bugs in that filesystem? Put on your resume that your main Linux contribution is as a diligent maintainer of that filesystem? You can't do that, because of the name. No development and maintenance, and it's dead.
Linus admitted that he only named one piece of software after himself and that was Git. Linux was a sort of half-hearted decision he only accepted as a last resort.
What other filesystems have checksums for data? Last time I looked, after a silent SSD failure that I only noticed because some .so files were affected, the only options were btrfs and reiserfs (I think ZFS required a custom kernel at that time).
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.
I use btrfs with snapshots for my backups. Not only do I get file checksums. The differences in files if I'm hit by ransomware or large-scale file corruption will draw my attention when the disk fills up.
ReiserFS has been stable for a long time, and especially useful for spinning metal disks that need to store lots and lots of small files. Not sure that there is a modern replacement that will be able to do this well.
- 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 are interesting links to slavery and workhouses by allowing people to do actual labor from prison.
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.
It's an open source project, that he originally contributed. It's a far cry from "slave work" if the work is voluntary and the result ends up in the digital commons.
In Greece you can optionally work while incarcerated, provided there is work to do for some of the prison's facilities, and each workday counts as two regarding your stay there.
For the same reason why prisons don't allow any other outside activity, whether commercial or not. This would require pretty big prison reform. And that is assuming he has any interest at all doing that.
Hans Reiser was reportedly impossible to work with in any event, as the Reiser4 debacle showed. I'm happy excluding him from the open source community.
Maybe someone with more understanding of kernel development could explain things to me.
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?
Not really, no. But you'd have to get the source and build the kernel module for the specific kernel it runs on. There are mechanisms to do this, such as DKMS (e.g. Virtualbox does this: it provides its kernel modules' code, OS/user provides kernel source, magic happens and sometimes it even works on the first try); having the module code always present in kernel source (even if it doesn't get built) is more convenient for building, but less convenient for kernel maintainers.
I wonder, how does the principle of not breaking userspace mesh with removing of file systems or drivers?
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.
I think, technically, file systems are not part of user-space. All of the code for file-systems lives in the Kernel.
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.
I disagree that filesystem support is not part of userspace.
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?
`mount -t reiserfs` will also fail if ReiserFS isn't built for the running kernel. mount(2) fails with ENODEV and prints an accurate message: "unknown filesystem type 'reiserfs'". This isn't breaking userspace. The syscall and program do the correct thing based on the capabilities of the current kernel.
In any case, the ship has long since sailed on removing filesystems from the kernel. The original extfs is no longer available, nor is xiafs, nor are some virtual filesystems like devfs, etc. "A command that used to do something no longer does because the feature is no longer in the kernel" is commonplace in Linux history and is not considered "breaking userspace".
According to wikipedia Hans might be out on parole next year. As part of his release agreement he should be required to maintain his namesake filesystem.
Can we just swap it for reiser4/5? It's only got a few people working on it but the FS is faster, has a plugin system for compression and other features, and is all-around just better. Call it shiskinfs if the name is problematic.
If paragon can get their cribbed together ntfs driver included in mainline then why can't reiser4 get merged?
Yes. Pretty much everyone is aware of the elephant in the room. It's just not relevant to address said elephant since it has no bearing on technical discussions, which is what the author of the e-mail thread pro-actively underlined.
The fact he is a murderer might not be relevant to the discussion per-se but his unavailability to help fixes/improvements to be made is a big issue as the author of the FS.
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?
Everyone understands the implications for a piece of software when its principal developer disappears. Wallowing in the details won't change anything. It's been years already.
Even if they do this cosmetic change now, take effort deal with silly regressions and reeducating users, it will still take quite some time for people to stop parroting in every thread about $newfs, that it's about “$newfs, previously known as reiserfs, originally authored by a convicted murderer”. This ship has sailed long time ago. Maybe there aren't that many users remaining now to begin with.
Honestly it was really great until it wasn't. I was there for almost ten years. The pay left a bit to be desired, but for the most part, everything else was so awesome that it was cool.
Then after some management changes, everything that made it great melted away and we were left with a job that underpays, has poor work-life balance, doesn't appreciate employee time/contributions, etc. It was still a pretty difficult decision to leave; management issues notwithstanding, the group of coworkers I actually worked with every day were - and still are - really great.
Companies associated with all kinds of crimes exists everywhere. For recent war crimes, you can search yourself. For WW2, there is even a wikipedia list of companies involved with the Holocaust. One of them even own RedHat Linux now.
https://en.wikipedia.org/wiki/List_of_companies_involved_in_...
I'm not seeing the snark in the email? Reiser was infamous for murdering his wife, and I'm guessing Wilcox doesn't want the discussion derailed by Reiser's sordid history.
>Does reiserfs still have a large install base that is just very happy with an old stable filesystem? Or have all its users migrated to new and exciting filesystems with active feature development?
It’s a bit of a stretch but I guess you could interpret calling a 20 years old FS “old” as snarky?
Though of course that it hasn’t received any major update in the last 15 years and is fast approaching major issues (iirc it’s not y2038-safe) are factors.
Implicit in Wilcox e-mail is the claim that there is a non-trivial cost of keeping reiserfs even when it is not being updated. Cost of keeping resierfs in the kernel > Cost of removing it. A filesystem is like a plugin for the kernel. In theory, it doesn't care what filesystem you use because it only access it using a common plugin interface. So keeping reiserfs in the kernel should cost 0. In practice, the cost is higher. Young developers often don't understand that. Plugins, extensions, modules, backends, what have you, no matter how great the extension mechanism is, you can't completely eliminate the costs.
In this case, ReiserFS was actually complicating an interface. But interestingly, a patch to resolve just that was published as a follow-up to the message this is all about.
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?
Removing a kernel driver does not break userspace.
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.
You're technically correct, but it would be a "fun" surprise to update your operating system and then not be able to boot because your filesystem isn't supported anymore.
If you're running a rolling release, you should already expect this kind of experience.
If you run a stable distribution, you stay on the older kernel series until you upgrade the entire OS, by which time the release notes would say "Removed support for ReiserFS"
And then there you can do the "tar -c -C /reiserfs . | tar -x -C /ext4" dance (or whatever other preferred copying mechanism), before the OS upgrade.
Such big changes rarely happen overnight. If someone really knows about and runs ReiserFS, they can be expected to read up on release notes for major upgrades of their distro. And it's far from an everyday event to even consider deprecating a filesystem. The fact that we are having this conversation rather proves that.
If your application interfaces with ReiserFS directly (fsck/servicing scripts), or you expect to see certain performance patterns (like high speed on lots of smaller files), then I would consider this userspace breakage.
In the same sense, Linux broke userspace for 386 users in 3.8 because the users expected Linux to run on their computer. An optional build-time feature being removed does not break userspace.
It isn't breaking userspace under the definition intended by "we do not break userspace". In that thread, Linus was referring to a kernel change that changed the error returned from an ioctl, which caused a program not just to fail (as it might if it tried to use a feature not compiled into the kernel) but to break (by entering an infinite loop).
I mean, at the end of the day ReiserFS offers very little special compared to the other options already in the kernel. It never had a huge install base and has always been a major maintenance burden on the kernel.
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.
There is a huge difference between introducing glitches in syscalls and deprecating support for something self-contained like a filesystem. The former is sudden and potentially impacts an unspecified, though presumably huge, number of users. The latter is a filesystem that will be put on a deprecation schedule that will literally take half a decade to go through.
Read on: "If a change results in user programs breaking, it's a bug in the
kernel." Linux regularly removes features. Entire architectures have been removed, including support for the 386. The alternative would be simply unworkable.
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.