From: Hans Reiser <reiser@namesys.com>
To: Larry Weldon <larry@welcoin.com>
Cc: reiserfs mailing list <reiserfs-list@namesys.com>
Subject: Re: rebuild-tree
Date: Mon, 08 Dec 2003 18:51:29 +0300 [thread overview]
Message-ID: <3FD49E01.9090502@namesys.com> (raw)
In-Reply-To: <1070829963.2789.528.camel@larry>
Larry Weldon wrote:
>A client's production file server is set up using RAID-1 with 2 IDE
>disks and reiserfs. The operating system is Mandrake 9.1.
>
which kernel does it use?
>=======================================================================
>Unfortunately, the tree structure used is also the weak point of
>ReiserFS: if any of it gets corrupted, chances are that much more data
>will be affected than under traditional FileSystems. Rather than losing
>a single file to corruption of an inode, you may lose almost the entire
>contents of your disk if metadata close to the root of the BTree is
>affected. Fortunately, the likelihood of this happening due to bugs has
>been dramatically reduced in more recent version of the driver. Hardware
>failure caused corruption is still a serious problem, though.
>========================================================================
>
>
The guy who wrote this does a nice job of telling one everything about
himself except his email address.
I don't know why he says this, and I don't think it is true. If you
trash the blocks with the root directory in any filesystem you are going
to end up with a lot of files in lost+found, yes?
Maybe others have a different experience or understanding of the remark.
With reiserfs, if you corrupt the internal nodes of the tree, you have
to run fsck before you can use it, and in this we are more fragile, but
once fsck has been run it is no more fragile than anything else
(assuming you use the latest fsck, because fsck took a long time to
stabilize).
>Now, I can't just stop using reiserfs and I don't want to. I think there
>is great merit in it. So, first, with the limited info I have given,
>what might have happened to create the problem and how likely might it
>be to happen again? Secondly, what is the *real* hazard of corruption
>_higher_up_ in the tree which the article says might blow away the whole
>partition?
>
>Thanks and regards.
>
>
--
Hans
next prev parent reply other threads:[~2003-12-08 15:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-07 20:46 rebuild-tree Larry Weldon
2003-12-08 11:01 ` rebuild-tree Vitaly Fertman
2003-12-08 15:51 ` Hans Reiser [this message]
2003-12-09 11:16 ` rebuild-tree Larry Weldon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3FD49E01.9090502@namesys.com \
--to=reiser@namesys.com \
--cc=larry@welcoin.com \
--cc=reiserfs-list@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.