>>>> What should a filesystem driver do if it can't suddenly read or write any
>>>> blocks on media?
>>>
>>> Maybe stopping gracefully, warn about what happened, and let the system
>>> keep going. You may be right about your main filesystem, but in the case
>>> I'm running, for example, my system in an ext3 filesystem, and have a
>>> vfat from a usb key. Should my system really hang because I'm not able
>>> to read/write to the device?
>>
>> getblk won't fail because of I/O error --- it can fail only because of
>> memory management bugs. I think it's right to stop the system in that case
>> --- it's better than silently corrupting data on any device.
>>
>> Mikulas
>>
> In the code, we see:
>
> if (unlikely(size & (bdev_hardsect_size(bdev)-1) ||
>                        (size < 512 || size > PAGE_SIZE))) {
>
> This is where __getblk_slow, and thus, __getblk fails, and it does not
> seem to be due to any memory management bug.

This is a filesystem bug --- filesystem should set it's blocksize with 
sb_set_blocksize (and refuse to mount if the device doesn't support it) 
before using it in requests.

Mikulas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/