Live data from Hacker News

Is it time to remove reiserfs?

lkml.org

131–140 of 260 posts

Re: Is it time to remove reiserfs?

#131
post #83

Earlier quoted context omitted.

> The logical successor was supposed to be btrfs, but that project IMHO may never be ready for production use. 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.

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?

> Is there a reason for that?

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.

Re: Is it time to remove reiserfs?

#132
post #83

Earlier quoted context omitted.

> The logical successor was supposed to be btrfs, but that project IMHO may never be ready for production use. 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.

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?

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.

Re: Is it time to remove reiserfs?

#133

I, for one, don't understand why can't they give Hans a computer and an internet connection and allow him to work on some open-source project.

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.

Re: Is it time to remove reiserfs?

#134

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.

Have you tried btrfs? It has tail packing, block subdivision and inline files.

Is btrfs stable yet?

Re: Is it time to remove reiserfs?

#135
post #25

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 c…

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 na…

[deleted]

Re: Is it time to remove reiserfs?

#136
post #46

Earlier quoted context omitted.

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?

It is not like he would be the only person capable of contributing into it ever.

Re: Is it time to remove reiserfs?

#137

Earlier quoted context omitted.

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.

Re: Is it time to remove reiserfs?

#138
post #29

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 thin…

> The logical successor was supposed to be btrfs, but that project IMHO may never be ready for production use. 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.

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.

Re: Is it time to remove reiserfs?

#139

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.

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.

Re: Is it time to remove reiserfs?

#140
post #86
post #51

Earlier quoted context omitted.

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…

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.

  > 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?
Post reply on HN