Re: [PATCH] mmc: Multi-sector writes

[Pavel Machek <pavel@xxxxxx>]

Hi!

> >>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
trash #2
good data #2
trash #1

I'm not sure how much journalling filesystems will like that in their journals...

-- 
64 bytes from 195.113.31.123: 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/