Reiser4 File-System Benchmarks With Linux 4.17

[colombo]

I know this is old thread and I am new (hello! ) and I am sorry for necroing, but this is the most recent thread on Phoronix about reiser4 fs. I´ve been researching for best FS for nvme and after 3 months of studying and comparing, reiser4 seems to be the most advanced FS for generic PC use. I dont mean for file hoarding on server - ZFS does better job there, or mobile phones - thats f2fs or ext4 area.

For example, reiser4 has three allocators - journal overwriter like ext4, the full cow like wa, and the hybrid mode, which is default and which tries to minimize fragmentation, and this was invented like in 2004? The enormous fragmentation issue, which f2fs and btrfs have (here is an example), which btrfs tries to solve by autodefrag, which causes additional write overhead (critical for nand) and to solve which some research was done only last year for f2fs - it does not exist in reiser4, because the system tries to minimize fragmentation and write cycles by itself.

As usual with these benchmarks there are some discussion about options:
1. BTRFS had COW enabled, Reiser4 did not (use txmod=wa to enable it, you get much more IOPS that way);
2. Reiser4 had compression enabled (create partition with create=reg40 to disable it), others didn't.

Exactly this, reiser4 was tested with compression and in tidy-up mode, where the rest was spamming the disk with fragments, except for ext4/xfs that win through preallocation of the structures. Plus, reiser4 can be optimized further - it uses default 10 minute commit interval (tmgr.atom_max_age=600) - where btrfs commits at 30 seconds; and the flushers are limited at 1(tmgr.atom_max_flushers) - which may have been good for hdd, but 30 look more like it for nvme. Also, sadly, the total written bytes wasted for each fs is missing - a thing hard ignore for consumer nvme.

I also find that Btrfs tries to cheat in read performance by using 16k optimized metadata units (remember, it DUPs them) , which allow it to read data much faster, but at same time cause huge write amplification. For example, f2fs uses only 4k with 2048 file inlining. reiser4 is already using 4k, plus it stores checksums inside metadata to further decrease write amplification - and it has inlining disabled, but its also possible.

The only thing I am missing on reiser4 seems to be some raid1-like data duplication (data dup in btrfs terms), but thats probably what reiser5 is trying to achieve. Too bad this awesome system is denied being used in kernel due to some political agenda. People seem to be reinventing the wheel today, which was done several decades old.

[eltomito]

Every time I see news about reiser all that comes to mind is that it was developed by a murderer...

The more the reason to expect it to deliver killer benchmark results.

[PeeJay]

I was astonished about Btrfs. Did it get faster?

Yes, somewhat, although there was a huge increase in delete speed recently.

[stiiixy]

Thanks for those, Mick. Interesting notes in comments regarding the compression etc affecting a proper bench run however. Is anyone able to provide a PTS link to their own reiser4 tests with a more even comparative surface?

[timofonic]

Every time I see news about reiser all that comes to mind is that it was developed by a murderer...

Don't troll, your post it's stupid. This is about technology, not about yellow press.

[BiG_NoBoDy]

Every time I see news about reiser all that comes to mind is that it was developed by a murderer...

Have you seen it personally? The whole motive why all things happen? If not, you cannot judge only a final step, some other "Gods" did it already.
In many cases approved aggression comes only from male to female, but now in most cases female is provoking it by "invalid argument" and so on
And that some person was selfish and wanted attention to herself, I would say so, that lead to some fatal activity in Reisers family life... and that's so pity!
Like the water drop constantly falling on a rock would make a hole in it? No, we need additional factors, like wind, temp, seasons, day and night and others...

To author: Please take in consideration that Reiser4 was here many years before any ext4 and others came to the game.
Also I understand a point of author, that tests were done for end user usability performance, but please also mention, how much info you can put on FS of text and other type.
Also how it would work after power-loss during write (ext4 do not survive, I had it 3 times on my laptop). XFS and Reiser4 no issues so far even on constant power-loss . ZFS - had issues but removing cache, saved my day.

[linuxgeex]

The only thing I'd use Reiser4 for is a postfix mqueue. For that, it's brilliant. It used to have a huge advantage. Now EXT4 and XFS have zero-copy and extents which kick Reiser4 for throughput per CPU usage as well as reducing memory usage. I still have a hard time recommending BTRFS unless you really need the fine-grained snapshots, or have talked yourself into believing that the software data checksums are somehow better than the hardware checksums already performed by the storage device, controller, and driver. Myself, meh, I'm happy with the 4 billion to one chance of corruption above and beyond the error-correcting headroom above the Shannon Limit for the media, and so long as the driver agrees with the interface, I'm happy to believe the data came back verbatim. If you're running your Enterprise SAP on a USB thumbdrive without those hardware guarantees, then fill your boots with BTRFS lol.

[doublez13]

Every time I see news about reiser all that comes to mind is that it was developed by a murderer...

I just read the Reiser comments for the killer puns.

[TheOne]

Every time I see news about reiser all that comes to mind is that it was developed by a murderer...

[DusanC]

As usual with these benchmarks there are some discussion about options:
1. BTRFS had COW enabled, Reiser4 did not (use txmod=wa to enable it, you get much more IOPS that way);
2. Reiser4 had compression enabled (create partition with create=reg40 to disable it), others didn't.