linux-ext4 - RE: 2nd Attempt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <001601ce482e$07282510$15786f30$@ntlworld.com>
Date:	Fri, 3 May 2013 19:42:55 +0100
From:	"Stephen Elliott" <techweb@...world.com>
To:	"'Theodore Ts'o'" <tytso@....edu>
Cc:	"'Andreas Dilger'" <adilger@...ger.ca>,
	<linux-ext4@...r.kernel.org>
Subject: RE: 2nd Attempt - FSCK Errors

Thanks very much... I do appreciate you guys are developers and not support
people :) The only thing is it is difficult to try and grasp an
understanding when troubleshooting FS problems, since they generally just
resolve themselves in my experience (Slackware linux user for 10+ years).

We have another NAS which acts as a warm standby. To be on the safe side, I
tested debugfs on that just to ensure it didn't crash the box etc. The
standby box is running totally clean.

One thing maybe you could explain (and Andreas gave me his take too) is how
you can multiply assigned blocks shared with "0" files. Andreas offered the
suggestion that they may be in the same file. If this were really the case,
I would suspect there to be some file corruption issues etc...

I think I am going to move the file off the device, run FSCK and then put it
back on and monitor.

-----Original Message-----
From: Theodore Ts'o [mailto:tytso@....edu] 
Sent: 03 May 2013 16:29
To: Stephen Elliott
Cc: 'Andreas Dilger'; linux-ext4@...r.kernel.org
Subject: Re: 2nd Attempt - FSCK Errors

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

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html