| |||||||||||||
|
| |||||||||||||
ReiserFS's stability is not actually quite goodReiserFS's stability is not actually quite goodPosted Apr 26, 2006 21:24 UTC (Wed) by nix (subscriber, #2304)In reply to: ReiserFS's stability is not actually quite good by nix Parent article: Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch (Debian Administration)
Lest I seem excessively harsh, I'm only talking, oh, ten panics in four years here. But still that's ten panics more than ext2, ext3, or xfs have ever hit me with. (ext3 even coped on a machine with RAM so bad you couldn't md5sum a 10Mb file twice in a row and get the same answer!)
(I had major disk corruption on ext3 once, but when your disk drive decides to put blocks somewhere other than where the filesystem asked for them to go, you have little option but to get a new disk and restore from backup, really...)
Even with reiserfs, Linux is damned stable. But reiserfs doesn't help.
(Log in to post comments)
ReiserFS's stability is not actually quite good Posted Apr 27, 2006 13:36 UTC (Thu) by dmantione (guest, #4640) [Link] <I>I had major disk corruption on ext3 once, but when your disk drivedecides to put blocks somewhere other than where the filesystem asked for them to go, you have little option but to get a new disk and restore from backup, really...</I>
Yes, you would prefer to restore from backup.
However, if you did not backup the data, either due to cost/benefit
In such a situation the reiserfsck --rebuild-tree option, which you
* Connect a new disk with the same size or larger as the failing disk.
Your actual data loss depends on the severity of the corruption. I've had
It is easy to bash the --rebuild-tree option because it is not 100% safe
ReiserFS's stability is not actually quite good Posted Apr 27, 2006 23:43 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] so you are saying that reiserfs knows better then the admin. personally I won't use software that decides it knows what I should do better then I do (good defaults are one thing, engineering the product to not allow for choice in another)
you are overlooking the fatal flaw with rebuild tree, namely it grabs ALL blocks that look like they are reiserfs tree blocks, unfortunantly with loop mounted filesystems you can have many filesystems on one partition (the main one, and then the ones that are images in files), rebuild tree will try to combine them all.
ReiserFS's stability is not actually quite good Posted Apr 28, 2006 5:32 UTC (Fri) by dmantione (guest, #4640) [Link] Since it is an optional feature, and you are not required to use it, I donot see the problem.
ReiserFS's stability is not actually quite good Posted Apr 29, 2006 11:00 UTC (Sat) by nix (subscriber, #2304) [Link] I can't imagine *any* filesystem saving my data if the disk has been placing blocks in the wrong place for five minutes during intense writes (which was what happened here).
reiserfsck is not going to be any luckier here than any other repair tool because the data is *overwritten*. --rebuild-tree is not magical (any tool which can be misled by the *contents of files* deserves a rather different word to describe it).
ReiserFS's stability is not actually quite good Posted Apr 28, 2006 4:46 UTC (Fri) by zooko (subscriber, #2589) [Link] You would prefer that the filesystem optimistically ignore errors when it can and the admin can restore from backups if that goes bad. This is a reasonable strategy for some workloads, where availability is more important than correctness in the short term, and the admin can manually restore correctness in the long term. If you have such a workload, you should probably not user ReiserFS. If on the other hand you have a workload where correctness is more important than availability, then ReiserFS would be a good tool for that use.
Regards,
Zooko
ReiserFS's stability is not actually quite good Posted Apr 29, 2006 11:02 UTC (Sat) by nix (subscriber, #2304) [Link] No, of course not. If an error is detected, the FS should go read-only as far as is possible so that data recovery can continue and the system can at least stay mostly running.
This is trivially possible: ext2fs and ext3fs both do it. That reiserfs does not is not to its credit.
ReiserFS's stability is not actually quite good Posted May 8, 2008 15:57 UTC (Thu) by zooko (subscriber, #2589) [Link] Hello. Two years ago was the last comment in this thread, and here I am to add another one. :-) My comment is that this fault-injection analysis: https://www.cs.wisc.edu/wind/Publications/iron-sosp05.pdf says that what ext2fs and ext3fs do for many of the errors that they measured is nothing, i.e. carry on as if nothing happened. What reiserfs does for those same errors is stop. You could argue that switching to read-only mode would be better than stopping. I don't know about that. Perhaps the "propagate" option in iron-sosp05.pdf would be better than the "stop" option because then outer layer code (i.e. the kernel or even userland) can detect the error and remount read-only. But, as far as comparing the safety of ext2fs and ext3fs vs. reiserfs, the iron-sosp05.pdf document seems to make it clean that ext2fs and ext3fs err on the side of increased availability at the cost of higher risk of corruption, where reiserfs errs on the side of increased correctness at the cost of higher risk of unavailability.
ReiserFS's stability is not actually quite good Posted May 8, 2008 22:18 UTC (Thu) by nix (subscriber, #2304) [Link] I'm still here :) That increased availability is important. As I see it, there are two types of file storage one might be interested in. There's files for which availability is more important than correctness-of-content-under-errors, and there are files where integrity is all. The former case should be handled by detecting errors and going read-only (i.e. what ext2+ does, only perhaps with added integrity hashes so you can spot more failure cases). The latter case should be handled by making *the filesystem objects that are corrupted* unreadable (not the whole disk unless there's so much corruption that you can't be sure of anything). Files that satisfy the former constraint are far more common than those that satisfy the latter, because you almost always want the fs to be mountable so you can recover as much as possible before hitting the backups. Files that satisfy the latter constraint... well, I'm trying to think of any and I'm coming up cryptographic keys. (Definitely not financial data: I work in that industry, and what matters there is availability above all. If one bit is flipped you cope and carry on, you don't go unavailable: after all, your competitors haven't stopped just because you're having system problems...) Of course neither fs satisfies these constaints: reiserfs stops too hard (and panics the whole machine!), ext* doesn't spot enough failures before they cascade into something horrid. Recently I had a failure mode where the heads didn't bother to move after a journal write, leading to rubbish dumped into the journal. The drive went more demented shortly after that, mashed another fs, and the machine got rebooted... and ext3 thought ooh, we can just roll the journal forward! Oops, wrong, that scattered more corruption around, and because no fsck had been done the first we knew of it was when a dozen NFS mounts from that filesystem suddenly went read-only. e2fsck did a sterling job and got essentially everything back, even though we had part of an inode table claimed simultaneously by the journal inode and by a bunch of logfiles, with a bunch of logfile output written into it in place of inodes. (e2fsck wasn't stupid and realised that this was in an inode table so the other two files must be liars. Obviously we lost the metadata for most of those files, but all the important stuff came back OK. Amazing.)
|
|
||||||||||||