From: "Stephen Elliott" <techweb@ntlworld.com>
To: "'Theodore Ts'o'" <tytso@mit.edu>
Cc: "'Andreas Dilger'" <adilger@dilger.ca>, <linux-ext4@vger.kernel.org>
Subject: RE: 2nd Attempt - FSCK Errors
Date: Fri, 3 May 2013 14:31:41 +0100 [thread overview]
Message-ID: <002701ce4802$8c4e4fc0$a4eaef40$@ntlworld.com> (raw)
In-Reply-To: <20130503131421.GC32297@thunk.org>
Well... Funny enough, the device which I ran debugfs on was the other
ReadyNAS device, not the one with the issue anyway. I wanted to test it
first.
I suspect the underlying architecture supporting RAID in these devices
screws with the debugfs interface.
I just find it bizarre that I get the same message regarding multiply
assigned blocks in 0 files on every FSCK as in it never gets resolved.
But... No issues with file access or no bad logs etc. I do have a case open
with Netgear support, since this is basically an appliance.
-----Original Message-----
From: Theodore Ts'o [mailto:tytso@mit.edu]
Sent: 03 May 2013 14:14
To: Stephen Elliott
Cc: 'Andreas Dilger'; linux-ext4@vger.kernel.org
Subject: Re: 2nd Attempt - FSCK Errors
What you've shown us makes me suspicious about whether the hardware device
is sane or not. In the previous e2fsck run, it set i_size to a non-zero
value. Yet when debugfs tries to read the same inode, it's now seeing all
zero's.
So that implies the disk (or software raid device; you haven't been clear
what the underlying storage is for this file system) is not returning the
same information for a particular block as was previously written.
If the underlying block device is not stable, there really is nothing for
e2fsck to do. You might want to check /var/log/messages for any error
messages relating to the underlying storage device(s). If you're seeing I/O
errors in the log files, that would be another hint.
At this point, my recommendation to you is to find a separate disk (or RAID
array if necessary) which is as big as the underlying disk, and do an image
copy (via dd or ddrescue) to a known-good storage device, and then retry the
e2fsck on this copy of the file system.
Regards,
- Ted
next prev parent reply other threads:[~2013-05-03 13:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-30 14:00 2nd Attempt - FSCK Errors Stephen Elliott
2013-04-30 16:14 ` Andreas Dilger
2013-04-30 16:25 ` Stephen Elliott
2013-04-30 17:58 ` Stephen Elliott
2013-05-03 10:55 ` Stephen Elliott
2013-05-03 13:14 ` Theodore Ts'o
2013-05-03 13:31 ` Stephen Elliott [this message]
2013-05-03 15:29 ` Theodore Ts'o
2013-05-03 18:42 ` Stephen Elliott
2013-05-03 21:31 ` Theodore Ts'o
2013-05-05 11:19 ` Stephen Elliott
2013-05-08 14:45 ` Stephen Elliott
-- strict thread matches above, loose matches on Subject: below --
2013-05-08 15:20 Stephen Elliott
2013-05-08 16:22 ` Andreas Dilger
2013-05-08 16:25 ` Stephen Elliott
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='002701ce4802$8c4e4fc0$a4eaef40$@ntlworld.com' \
--to=techweb@ntlworld.com \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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.