Reiser4 File-System Is Still Ticking In 2019 - Now Updated For Linux 5.3 Compatibility

[computerquip]

Who is the userbase of ReiserFS anyway?

Embedded and small partitions in my experience though I don't know why.

[timofonic]

Who is the userbase of ReiserFS anyway?

Mysogenic men that want to kill his wife?

[profoundWHALE]

This is silly bickering. It's clear that Reiser4 is stable and well supported by their own developers and have been following kernel releases for years now.

Just add it to the kernel so we can stop wasting time making jokes about murder.

Thanks.

[linuxgeex]

Reiser4 has really good performance with small files. It was meant to basically use your filesystem as a NOSQL data store. It combines multiple small files into a single 4k block where it can. Before HTML email really caught on it was excellent for smtp daemon mailspool use. It would be fabulous for SMS-C and large-scale BIND9 deployments.

[GI_Jack]

*yawn*

who fucking cares? Ext4 is rock solid, so is F2FS, JFS, and XFS. There is no compelling technical reason for Rieser4 or any version. There is no use case scenario, and no reason to include this in the tree. we have enough file systems.

Also, its named after a man who murdered his mail order bride, so just do us all a favor and just drop it.

[SystemCrasher]

Can't wait to see if it kills other file systems in the benchmarks.

Filesystems are not for winning in benchmarks. They are about storing and retrieving files, to begin with. Somehow e.g. Reiser3 wasn't exactly good at later: it could eventually come to state it totally refuses to mount and fsck would just totally obliterate filesystem while trying to "fix" it. "Known issue" as said by Reiser devs, lol. Oh, look, /dev/null got infinite capacity, would be decent in benchmarks, and if you give no crap about reading your files back anyway...

Look, filesystems take a lot in terms of getting them work in real world scenarios. Especially when it comes to getting your files back on imperfect or even obviously faulty hardware.

[SystemCrasher]

*yawn*who fucking cares? Ext4 is rock solid, so is F2FS, JFS, and XFS. There is no compelling technical reason for Rieser4 or any version. There is no use case scenario, and no reason to include this in the tree. we have enough file systems. Also, its named after a man who murdered his mail order bride, so just do us all a favor and just drop it.

Funny enough, "rock solid" EXT4 just miserably fails me here and now... due to few bad sectors on flakey SD Card that hit metadata area. Guess what happens next. Well, the only solid thing it did is moaning about corrupt metadata - and doing that without crashing or hanging, so yes, at least code quality isn't crap. However, access to data totally wrecked at this point, hell a lot of files just unreadable - just because metadata failed to read, so while data is here, description how to get that back is not. Quite a problem, isn't it?

Guess what I would put next time in comparable scenario? That would be btrfs - using DUP storage profile at least for metadata, if not data. Later halves available space, but makes things far more survivable in imperfect scenarios. Wouldn't help against complete device failures, but surely survives sporadic bad sectors and somesuch. Even if these elect to come under metadata. Actually I had some funny experiments to run btrfs on really borkzored HW. It does nice job telling HW misbehaves - and even can get around it most of time, getting most if not all data back. And if things go really bad, btrfs is the only Linux filesystem I know that got "offline" recovery tools that do not rely on mounting FS. So even if that fails to mount, there're quite some ways to get most data back. Btrfs design also implies there're multiple re-parse entry points, so if something totally damaged, you can try to enter at slightly different "generation" and there is chance it would work. Maybe at cost of slightly old state or so. But at least it would parse most of filesystem using more or less workable set of metadata and retrieve most of files.

Just doesn't works this way with XFS or JFS... thesr are doomed to suffer terrible loses on single device setups even on slight imperfections. And when I gave a hardcore rundown, F2FS haven't survived ... just more or less usual power loss crash. Entering some odd state where neither kernel is willing to mount that, nor its fsck being able to fix damage. Cool, isn't it? Result is total loss of access to data. And all that on mere powerloss crash?! So I wouldn't call F2FS rock solid for now. Hopefully it also gives idea why tools to do "offline" reading from filesystem are good idea - if that neither mounts, nor fixes to state where it mountable, getting yet another extra option helps, any day.

[GI_Jack]

Funny enough, "rock solid" EXT4 just miserably fails me here and now... due to few bad sectors on flakey SD Card that hit metadata area. Guess what happens next. Well, the only solid thing it did is moaning about corrupt metadata - and doing that without crashing or hanging, so yes, at least code quality isn't crap. However, access to data totally wrecked at this point, hell a lot of files just unreadable - just because metadata failed to read, so while data is here, description how to get that back is not. Quite a problem, isn't it?

Guess what I would put next time in comparable scenario? That would be btrfs - using DUP storage profile at least for metadata, if not data. Later halves available space, but makes things far more survivable in imperfect scenarios. Wouldn't help against complete device failures, but surely survives sporadic bad sectors and somesuch. Even if these elect to come under metadata. Actually I had some funny experiments to run btrfs on really borkzored HW. It does nice job telling HW misbehaves - and even can get around it most of time, getting most if not all data back. And if things go really bad, btrfs is the only Linux filesystem I know that got "offline" recovery tools that do not rely on mounting FS. So even if that fails to mount, there're quite some ways to get most data back. Btrfs design also implies there're multiple re-parse entry points, so if something totally damaged, you can try to enter at slightly different "generation" and there is chance it would work. Maybe at cost of slightly old state or so. But at least it would parse most of filesystem using more or less workable set of metadata and retrieve most of files.

Just doesn't works this way with XFS or JFS... thesr are doomed to suffer terrible loses on single device setups even on slight imperfections. And when I gave a hardcore rundown, F2FS haven't survived ... just more or less usual power loss crash. Entering some odd state where neither kernel is willing to mount that, nor its fsck being able to fix damage. Cool, isn't it? Result is total loss of access to data. And all that on mere powerloss crash?! So I wouldn't call F2FS rock solid for now. Hopefully it also gives idea why tools to do "offline" reading from filesystem are good idea - if that neither mounts, nor fixes to state where it mountable, getting yet another extra option helps, any day.

Reiser4 wouldn't save you here. ext4 is journaled as well. I've had a really bad time with BTRFS as well. As far as offline recovery tools, ext4 has plenty and is widely supported. testdisk, extundelete, ext4magic, heck even fsck. I am also not sure what you mean as they all work offline. In fact most recovery tools work offline without the partition being mounted, with only a handful working on mounted partitions.

In fact, benchmarks from a few years ago with Reiser4, even in the "small files" test, chokes against just about anything else on a modern linux kernel.