Reiserfs4

[tejecske]

[vipernicus]

I guess whether you use reiser4 or ext3, depends on if you are in a production server environment. Try to explain this to your VP's, "I decided to go with Reiser4, even though it is still in constant developement, that's why all of your documents and data are corrupt". Would you truly choose Reiser4 if your job depended on it? I am not going to make another reiser4 post, I didn't mean to start a flame war, opinions are only opinions, it's not like I said something against a religion. I am a Systems Administrator for a college, my servers need to be stable, that is the reason for my attitudes on things like that. On my desktop on the other hand, I've played around with Reiser4, and it was alright, though, latencies were higher than with ext3. but we all have our preferences, some geeks even still use ext2 for some reason or another.
_________________
Viper-Sources Maintainer || nesl247 Projects || vipernicus.org blog

[Xithix]

It depends on purpose and hardware. Saying "You ARE going to lose data! For sure! Others who claim they've been using it for years just haven't had their failure yet .. but they will!" is bollocks. The filesystem is stable. The disabled-by-default plugins (such as the cryptocompress one) are unstable. The kernels with reiser4 patches are often unstable (like mm-sources). The "development" on reiser4 you speak of is primarily on the plugins, and on the coding style, not on the base filesystem. Neither effect the base filesystem.

Would I use reiser4 on a production server? It depends. If the biggest concern is uptime and the infrastructure is flaky (say, a web server located in parts of Asia where power spikes are frequent) I would definitely use reiser4 (and a UPS). If the data stored was mission critical (say, a computer storing a bank's financial records, or a remote backup rsync server), I would use ext3.

Why Reiser4 on the uptime box? Because of its atomic nature. Journals are great, but you still need to fsck an ext3 partition a lot more than a reiser4 partition if something wonky happens to it. Reiser4's journal AND atomic writes makes it virtually impossible to require a fsck.

Why ext3 on the mission critical data box? Say something happens to the hard drives, physically, like an earthquake. This will corrupt ANY file system. But there are recovery tools for ext3. I don't foresee recovery tools popping up for reiser4 any time soon, so if there's data that NEEDS to be there which was written AFTER the most recent backup, ext3 is much more likely to be able to recover it.

I have no idea why people still use ext2 at all. Ext3 is exactly the same, but with a journal.

[Enlight]

Actually and by far the most reliable fs still is XFS, it's the most tested at this time, but people are often astonished by it's agressive deletion policy on recovery : as it is not atomic, file that were succeptible to be modified are deleted to prevent the existence of "Frankenstein" files.

Imagine that a file is spread over 3 logical blocks and you were just updating it when the crash / power failure happened (let's say only the half of the file was updated : here are the different policies :

XFS : this file is suspicious, let's delete it.
Reiser4 : Let's restore the file as it was before attempting to update it.
ext3/reiser-3.6 : the file is correct why shouldn't it be?

So imagine it's xorg.conf

XFS : X won't start because there is no xorg.conf FIY (FS integrity ok)
reiser4 : X would probably start and the probability of a new version of xorg (let's say we were updating it) not being with the old xorg.conf are feeble (fdon't know about integrity)
r-3.6/ext3 : xorg may start or atrocely die. || FS may be integrally corrupted

Now let's say it was a kernel update (or a module or whatever than can execute code in ring 0) and imagine the worst scenario :

XFS : no kernel, no boot FIY...
R-4 : boot normally with the old kernel and as you can't update glibc against an upper version than the one currently running there should be no problem
ext3/r-3.6 : triple fault severe damages to the hardware etc...


Now imagine that the administrator was drunk and ran the command that he shouldn't have (i.e. formated the disk as NTFS while booting on it's window partition):

R-4 : you're pretty fscked
XFS : mkfs.xfs $device && xfs repair $ device ==> at least 80% of your datas back
ext3/r-3.6 : ... don't know


So it's a matter of choice...

[tuam]

[tejecske]

[wilf]

Hi All,

I am really grateful for all comments - both for and against.

So thanks.

You've all enabled me to make my own decision - and to make a far better quality decision than I would have been able to do before asking.

Best Regards, Paul.

[azazello]

I have used reiser4 as my main filesystem for a while recently. For a few months, it was all good and pretty fast. Then I had a crash and it refused to mount or automatically fsck, which forced me to boot from another disk, but fsck fixed it. Finally I had a program fill the filesystem to full capacity, and not only did the kernel panic, it generated errors in the filesystem which were unfixable with fsck.reiser4. Thankfully it was still mountable despite the errors. At that point I decided to cut my losses and shuffled the system back to ext3.

I think reiser4 needs to see a few months in the mainline kernel before it becomes stable enough for general use.

[Jake]

[tejecske]

[vipernicus]

[Gentree]

[kernelOfTruth]

[sirdilznik]

[Gentree]

yep , it seems to be a weakness not having a reserve for sys. It's (nearly) always user error when it happens and R4 recovers well when it happens but a safety net would be a good feature since it can prevent the need to shut the system down to fix the problem.

maybe this should be put forward as an official request to Andrew Morton.


_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86