Russell King wrote:
>On Thu, Aug 18, 2005 at 09:26:03AM +0200, Pierre Ossman wrote:
>
>
>>We had this discussion on LKML and Alan Cox' comment on it was that a
>>solution like this would be acceptable, where we try and shove
>>everything out first and then fall back on sector-by-sector to determine
>>where an error occurs. This will only break if the problematic sector
>>keeps shifting around, but at that point the card is probably toast
>>anyway (if the thing keeps moving how can you bad block it?).
>>
>>
>
>There are two different kinds of error - the ones at the transport
>level which we are able to force a result of "no sectors transferred"
>for. For all other errors and successful completions, the driver
>reports "all sectors tranferred" since the driver level doesn't know
>that an error occurred.
>
>This causes us to tell the upper levels that we were successful,
>even if we weren't. Hence the problem.
>
>
>
I still don't understand where you see the problem. As you said there
are two problems that can occur:
* Transport problem. The driver will report back a CRC error, timeout or
whatnot and break. We might not know how many sectors survived so we try
again, going sector-by-sector. We might get a transfer error again,
possibly even before the previous one. But at this point the transport
is probably so noisy that we have little chans of doing a clean umount
anyway. So when the device gets fixed, either by replaying the journal
or doing a fsck, it would have been in the same state if we would have
been able to tell exactly which sectors got written.
* Media error. If the card fails to write data to flash then it will set
the corresponding bits in the status register. We do not check these ATM
so any errors there will get overlooked. So I fail to see how this would
be different when writing several sectors at once. If we implement this
check we will not know where the card failed its write, but again we
fall back to sector-by-sector in this case to determine exactly where
the card has problems.
Rgds
Pierre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|