[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <p06240522c5b1d7426151@[10.1.5.33]>
Date: Fri, 6 Feb 2009 13:18:38 +0100
From: "J.D. Bakker" <jdb@...tmaker.nl>
To: Eric Sandeen <sandeen@...hat.com>
Cc: linux-ext4@...r.kernel.org
Subject: Re: Recovering a damaged ext4 fs - revisited.
At 22:02 -0600 05-02-2009, Eric Sandeen wrote:
>J.D. Bakker wrote:
> > Error writing block 1 (Attempt to write block from filesystem
>> resulted in short write). Ignore error? no
>> Error writing block 2 (Attempt to write block from filesystem
>> resulted in short write). Ignore error? no
>> Error writing block 3 (Attempt to write block from filesystem
>> resulted in short write). Ignore error? no
>> [...]
>> Error writing block 231 (Attempt to write block from filesystem
>> resulted in short write). Ignore error? no
>> Error writing block 232 (Attempt to write block from filesystem
>> resulted in short write). Ignore error? no
>>
>> (full log at http://lartmaker.nl/ext4/e2fsck-md0.txt)
>
>Those seem a bit odd; why are these write failing? Anything in the
>kernel logs when this happens? I'm just wondering if there could be
>some underlying storage problem?
No, nothing in the logs.
Isn't this a side-effect of me passing the -n option to e2fsck? I
haven't traced the full path in the e2fsprogs-source, but it would
appear that the -n option sets E2F_OPT_NO, which sets
E2F_OPT_READONLY, which clears EXT2_FLAG_RW, which (in a few places)
clears IO_FLAG_RW, which appears to open the fs RO (as expected).
JDB.
[I passed -n to e2fsck as I want to keep the fs as untouched as
possible, and I don't have 4TB in scratch space handy to park a copy]
--
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lartmaker.nl/
--
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
Powered by blists - more mailing lists