Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is it time to remove reiserfs?

lkml.org

Post reply on HN
Print view View original

51–60 of 260 posts

Re: Is it time to remove reiserfs?

#51

Post by Syonyk »

cestith wrote: 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…

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.

Re: Is it time to remove reiserfs?

#52

Post by captainmuon »

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.

Re: Is it time to remove reiserfs?

#53

Post by cormacrelf »

marginalia_nu wrote: post #10

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.

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.

Re: Is it time to remove reiserfs?

#54

Post by fest »

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.

Re: Is it time to remove reiserfs?

#55

Post by [deleted] »

more_corn wrote: post #35
daneel_w wrote: post #13

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.

Isn’t it relevant though? The sole author and support person is AFK for the foreseeable future.

[deleted]

Re: Is it time to remove reiserfs?

#56

Post by madphilosopher »

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.

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

Re: Is it time to remove reiserfs?

#57

Post by pmarreck »

hughrr wrote: post #32
lillecarl wrote: post #31

Earlier quoted context omitted.

https://www.sqlite.org/fasterthanfs.html They're selling it quite well here, though integration into other products might be the hard thing.

Add https://github.com/guardianproject/libsqlfs

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).

Re: Is it time to remove reiserfs?

#58

Post by samhw »

codazoda wrote: post #28

> 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.

No post body was provided.

Re: Is it time to remove reiserfs?

#60

Post by marginalia_nu »

cormacrelf wrote: post #53
marginalia_nu wrote: post #10

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.

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.

Do zip files really offer performant random access with tens of millions of entries?
Post reply on HN