[Gllug] [Fwd: Server]

[Daniel P. Berrange]

On Sun, Nov 30, 2003 at 01:05:16PM +0000, Nix wrote:
> On Thu, 27 Nov 2003, Richard Jones moaned:
> [on reiserfs]
> > The design of the filesystem (ie. without blocks) pretty much ensures
> > that any corruption can't be recovered manually.
> 
> Er, reiserfs has blocks; even reiserfs4 has blocks.
> 
> Sure, tail packing means that the ends of multiple files can be squashed
> together in a single block, but that's hardly radical: I mean, even FFS
> does it!
> 
> (The tree layout makes it tricky to recover, though.)

Tricky to recover is one thing - but the sheer stupidity of the recovery
tools is what really finished reiserfs off for me. 

My entire machine hung Oracle was loading a schema, no problem I thought, 
I'll just reboot - the worst that could happen is that I'll corrupt
the data files & have to restore my DB from the previous day's exports.

Oh how wrong I was :-( The reiser integrity check & automatic recovery
failed upon boot up, telling me to run the reiser equiv of fsck. When
I ran that I printed a huge warning saying this problem was not to
be trusted! Then during 'recovery' it printed a tonne of messages
about unattached subtrees, however, rather than attaching all these
subtrees to 'lost+found' like any sensible UNIX filesystem it simply
discarded them for good. The result was I basically lost the entirity
of /usr/X11, /usr/lib, /usr/local and /var & had to rebuild from 
scratch. A file system & recovery tools that can cause that much damage 
to unrelated parts of the disk are a non-starter for any desktop,
let alone a server. 

On the other hand ext2 & e2fsck never fails to impress me - I had hardware
failure on a disk a little while back & it managed to rebuild the disk from 
copies of the super block 5 times[1] - enough for me to get all my important 
data off.

Reiserfs is like a car without brakes, side impact bars, or an airbag.

Dan.

[1] I'd boot, run e2fsck to repair the disk, start copying data,
    the kernel would panic, repeat....5 times.
-- 
|=-               http://www.berrange.com/~dan/gpgkey.txt             -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20031201/a7c11fd3/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug