All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Stephen Elliott <techweb@ntlworld.com>
Cc: 'Andreas Dilger' <adilger@dilger.ca>, linux-ext4@vger.kernel.org
Subject: Re: 2nd Attempt - FSCK Errors
Date: Fri, 3 May 2013 11:29:14 -0400	[thread overview]
Message-ID: <20130503152914.GE32297@thunk.org> (raw)
In-Reply-To: <002701ce4802$8c4e4fc0$a4eaef40$@ntlworld.com>

On Fri, May 03, 2013 at 02:31:41PM +0100, Stephen Elliott wrote:
> 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.

Was the inode number from the other device as well?  Sorry, this is
the first I've heard that there are two ReadyNAS devices in play.
It's one of the reasons why it's really painful to try to be a help
desk for these sorts of questions over e-mail....

> I suspect the underlying architecture supporting RAID in these devices
> screws with the debugfs interface.

Debugfs uses the standard Linux block device interface.  If that's not
sane, e2fsck isn't going to be sane either, and it's a kernel bug.  At
that point, you'll have to talk to ReadyNAS folks since they are
providing the kernel you are using (or the wonky non-standard
hardware, or both....)

> 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.

There have been NAS boxes out there which have used non-standard, out
of tree kernel patches that have resulted in their devices using
non-standard file system formats.  So that's yet another thing which
can't be ruled out...

						- Ted

  reply	other threads:[~2013-05-03 18:05 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
2013-05-03 15:29         ` Theodore Ts'o [this message]
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=20130503152914.GE32297@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=techweb@ntlworld.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.