From: Vladimir Saveliev <vs@namesys.com>
To: Andrew Snare <asnare@allshare.nl>
Cc: reiserfs-list@namesys.com, Paul Wagland <PWagland@allshare.nl>
Subject: Re: Block corruption
Date: Tue, 08 Jun 2004 18:12:26 +0400 [thread overview]
Message-ID: <1086703946.1830.96.camel@tribesman.namesys.com> (raw)
In-Reply-To: <s0c5dcfa.013@allshare.nl>
Hello
On Tue, 2004-06-08 at 17:36, Andrew Snare wrote:
> Hi,
>
> After a few 2.6.6 oopsen and --rebuild-trees on some filesystems, we've
> still got some bad-block errors that are proving troublesome. In
> particular, we appear to have 3 bad blocks:
>
> vs-5150: search_by_key: invalid format found in block 5963192. Fsck?
> vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to
> find stat data of [52570 52653 0x0 SD]
> vs-5150: search_by_key: invalid format found in block 5946544. Fsck?
> vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to
> find stat data of [46770 46771 0x0 SD]
> vs-5150: search_by_key: invalid format found in block 10058201. Fsck?
> vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to
> find stat data of [111684 111687 0x0 SD]
>
> It's a hardware RAID-5 configuration that has no errors, so we know
> it's not a hardware problem; this points to corruption in one or more of
> our 11 reiserfs filesystems.
>
> Is it possible to:
>
> 1) Work out which of the 11 filesystems these errors are referring to?
> Preferably while the system is mounted. I see a block number, but
> several of our filesystems are large enough to have a block number that
> big.
Well, reiserfs needs to include device name into its warnings
Until it is not done you might want to do
find /mountpoint -inum 52653
for each of your reiserfs filesystem.
> 2) Work out which directory/file is corrupted? In the past whenever we
> did a --rebuild-tree we ended up with quite a lot of stuff in
> lost+found, so we'd like to try and work out where it's coming from if
> possible.
>
the same find command should find those files.
Even better, find /mountpoint will say "Permission denied" for all files
unreachable on a filesystem
ALso, reiserfs may store more than one file in a node. So, few files may
be unreachable
> Thanks in advance,
>
> - Andrew Snare
>
next prev parent reply other threads:[~2004-06-08 14:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-08 13:36 Block corruption Andrew Snare
2004-06-08 14:12 ` Vladimir Saveliev [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-06-08 14:31 Andrew Snare
2004-06-08 15:55 ` Vladimir Saveliev
2019-08-31 18:19 block corruption Rann Bar-On
2019-08-31 20:26 ` Rann Bar-On
2019-08-31 23:04 ` Chris Murphy
2019-08-31 23:39 ` Rann Bar-On
2019-08-31 23:48 ` Qu Wenruo
2019-09-01 17:39 ` Rann Bar-On
2019-09-01 20:09 ` Chris Murphy
2019-09-01 20:35 ` Rann Bar-On
2019-09-02 5:33 ` Qu Wenruo
2019-09-02 6:27 ` Qu Wenruo
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=1086703946.1830.96.camel@tribesman.namesys.com \
--to=vs@namesys.com \
--cc=PWagland@allshare.nl \
--cc=asnare@allshare.nl \
--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.