Re: 2.a.30-rc7: fat filesystem misdetected as amiga
From: Andries E. Brouwer
Date: Mon May 25 2009 - 18:58:05 EST
On Tue, May 26, 2009 at 12:47:55AM +0300, Michael S. Tsirkin wrote:
> On Mon, May 25, 2009 at 05:08:12PM -0400, Alan Stern wrote:
>> On Mon, 25 May 2009, Michael S. Tsirkin wrote:
>>>> So apparently this is a bug in the device; it doesn't respond correctly
>>>> to the first READ command. But since it does respond correctly to
>>>> later commands, everything works okay thereafter. You ought to be able
>>>> to recover from the error by running
>>>> blockdev --rereadpt /dev/sdb
>>> Yes, this helps.
>>> Would it make sense for kernel to retry automatically?
>>> Why doesn't it?
>> I don't know the details in this case. Most likely the error code
>> (Logical Block Address Out of Range) is interpreted as a fatal
>> non-retryable error. For other sorts of errors, the kernel does retry.
>>>> As far as I can tell, this has nothing to do with any user programs in
>>>> the distribution. It appears to be entirely the device's fault.
>>>> Alan Stern
>>> BTW, any idea how come I later get errors apparently from amiga fs?
>> Not a clue. Unless it was some odd side effect of the partition code
>> trying to interpret an uninitialized buffer.
>> Alan Stern
The partition reading code tries one by one all partition types that
you have configured. If amigafs is one of these, also that will be tried.
I can imagine that your device is a slow starter and needs some time
to initialize itself, so that the first, or the first few, commands fail,
and after that all is well.
I hate retrying code. Such code is the reason that boot time increases
all the time. Usually a read failure is missing media or so, and retrying
is totally meaningless. Only at the lowest level should a retry be done,
and preferably not blindly "let us try a few times" but only when there
is a positive reason to expect that a second time might fare better.
(Amiga is not usually the first or second to be tried, so if it fails
then either the first few reads fail, or the first read failure is cached.)
> So, the following works for me as a work-around. But it's probably not
> the appropriate way to solve the problem. Or is it? Can someone who
> understands partitions and filesystems tell?
> block: retry on I/O error when reading partition table
> Retry once on an I/O error when reading the partition table:
> there's no much to loose, and this helps with some disk on
> key devices I have.
> Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx>
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/