From: Vitaly Fertman <vitaly@namesys.com>
To: hanasaki <hanasaki@hanaden.com>, reiserfs-list@namesys.com
Subject: Re: --rebuild-tree always finds errors --check is ok
Date: Mon, 10 Jan 2005 15:50:34 +0300 [thread overview]
Message-ID: <200501101550.34403.vitaly@namesys.com> (raw)
In-Reply-To: <41DF2CD6.7040800@hanaden.com>
On Saturday 08 January 2005 03:44, hanasaki wrote:
> Could you outline exactly what takes place on a rebuild-tree?
reiserfs has two types of blocks. There are unformatted nodes. They
contain plain user file data. And there are formatted nodes. These may
contain both user file data and filesystem metadata. --rebuild-tree scans
all blocks looking for filesystem metadata, e.g. for formatted nodes.
However you can put a reiserfs image into a file, then file data (e.g.
unformatted nodes of the host fs) will contain formatted nodes of the
fs image, and rebuilding of the host fs will be screwed up as there is
no way to distinguish image fs metadata kept in unformatted nodes
of the host fs from the host fs metadata.
> I was under the incorrect assumption that if a rebuild-tree is 100%
> successful then the FS is ok and a subsequent rebuild-tree will have
> nothing to fix/report. .....
In your case, some unformatted nodes look like formatted ones for the
first sight, however after fixing all the corruptions in these nodes fsck
realises that there is no valid metadata left and that they are either
completely broken nodes or file data ones. To not corrupt file data fsck
does not flush the made changes on disk. And as nothing gets changed
the same attempt of fixing these nodes repeats again on the next rebuild.
> Vitaly Fertman wrote:
> > On Tuesday 04 January 2005 20:25, hanasaki wrote:
> >>Version of reiserfsk
> >>======================
> >>== From debian sarge
> >>/sbin/reiserfsck -V
> >>reiserfsck 3.6.19 (2003 www.namesys.com)
> >>== also used the version in knoppix 3.7 with similar results
> >>
> >>the output of two consecutive runs of --rebuild-tree on the same
> >>unmounted partition are attached. Below is the diff
> >
> > rebuild-tree finds some blocks that looks like reiserfs formatted
> > blocks for the first sight whereas they are not and just belongs to
> > some file bodies. The consistency check reveals no valid metadata
> > in them, so they are considered as not valid reiserfs formatted blocks
> > and left not modified on disk. This is why the second run of rebuild-tree
> > finds them again and tries to do all the stuff again.
--
Thanks,
Vitaly Fertman
next prev parent reply other threads:[~2005-01-10 12:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-01 21:55 --rebuild-tree always finds errors --check is ok hanasaki
2005-01-04 14:30 ` Vladimir Saveliev
2005-01-04 17:25 ` hanasaki
2005-01-06 12:06 ` Vladimir Saveliev
2005-01-07 20:43 ` Vitaly Fertman
2005-01-08 0:44 ` hanasaki
2005-01-10 12:50 ` Vitaly Fertman [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-12-31 5:35 hanasaki
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=200501101550.34403.vitaly@namesys.com \
--to=vitaly@namesys.com \
--cc=hanasaki@hanaden.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.