Re: Corrupted/unreadable journal: reiser vs. ext3

[Sam Vilain <sam@vilain.net>]

On Wed, 12 Feb 2003 08:43, berthiaume_wayne@emc.com wrote:
> Dirk, I'd be interested in hearing from you your performance
> experience with ext3 when it reaches 96% full.

No problem, because you get ENOSPC at 95% or 90%.

Hmm, another feature SysAdmins actually find useful, missing in reiserfs.  
Along with quotas (this feature is a lazy case of a quota, really).

On Wed, 12 Feb 2003 18:12, Ross Vandegrift wrote:
> You have to start your software on some kind of foundation.  Working
> hardware sounds like a great place to me.

Hmm, you've never heard of redundancy or fault tolerance then.

What part fails the most in running systems ?  Disk platters.

CPUs might overheat and RAM might suddenly one day get a sticky bit, but as 
you point out there ain't much you can do about it.  Except buy a Tandem, 
or use ECC memory.

But with disks, you can.  Mirroring aside, modern hard disks use S.M.A.R.T. 
technology which claims to be able to spot failures before they happen.  
Many BIOSes will let you turn this feature on and off.  Of course I've 
never actually seen it in action :-).

Not only that, but re-attempting a failed read might just work.  In that 
case, you need to freshen the data (hopefully the disk will re-map the 
block once it sees a write), and if that fails, re-map the block.  I don't 
know if any of the other filesystems do that (I seriously doubt it), but 
it's what Norton 4.5 on DOS used to do to `repair' faulty disks :-).

But doing disk repair is entirely irrelevant for a filesystem.  What's 
important is that you don't get an Oops, a kernel Segfault or worse random 
data corruption or file structure mangling, that the calling process gets 
EIO instead.

Stopping random corruption from violating your assumptions is extremely 
difficult; a software engineer's nightmare :-).  However, modern disks are 
pretty good at keeping their own CRCs, so you should expect that you can 
always get an error code back from the OS if the data didn't come back the 
same state you wrote it.

You (the reiserfs team) need to wire up reiserfs on a custom loopback 
device, and selectively flick blocks to faulty and see what happens.  It's 
just a part of stress testing.

And there is no excuse - reiserfsck should do the right thing when it 
encounters a filesystem with bad blocks and recover what is possible, 
marking the bad blocks as bad.  It needs dd_rescue built into its 
operation :-).

It must suck having a free project get only slight funding.  All of a 
sudden a whole load of geeks get very angry and demanding.  I wish I could 
help, but hey it's more fun to troll.^H^H^H I've got better things to do.
-- 
Sam Vilain, sam@vilain.net

The reason we start a war is to fight a war, win a war, thereby
causing no more war!
 - George W. Bush during the first Presidential debate