[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] mmc: Multi-sector writes
> >>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
Well, but then you can get:
good data #1
good data #2
I'm not sure how much journalling filesystems will like that in their journals...
64 bytes from 22.214.171.124: icmp_seq=28 ttl=51 time=448769.1 ms
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/