mmc: Multi-sector writes

Adds support for writing multiple sectors at once. This allows back-to-back transfers of sectors giving roughly double write throughput.

To be able to detect which sector is causing problems the system falls back to single sector writes if a failure is detected.

...

drivers/mmc/mmc_block.c +7 -0

@@ -166,9 +166,25 @@
 	struct mmc_blk_data *md = mq->data;
 	struct mmc_card *card = md->queue.card;
 	int ret;
+	
+#ifdef CONFIG_MMC_BULKTRANSFER
+	int failsafe;
+#endif
 
 	if (mmc_card_claim_host(card))
 		goto cmd_err;
+	
+#ifdef CONFIG_MMC_BULKTRANSFER
+	/*

The fact that this is enabled under the experimental CONFIG_MMC_BULKTRANSFER seems unfortunate. I mean, if the code works OK then we should just enable it unconditionally, no?

I'm thinking that it would be better to not have the config option there and then re-add it late in the 2.6.14 cycle if someone reports problems which cannot be fixed. Or at least make it default to 'y' so we get more testing coverage, then remove the config option later. Or something.

Thoughts?

Quoted 6 lines

I'm thinking that it would be better to not have the config option there and then re-add it late in the 2.6.14 cycle if someone reports problems which cannot be fixed. Or at least make it default to 'y' so we get more testing coverage, then remove the config option later. Or something.

Quoted 3 lines

Thoughts?

Removing it would be preferable by me. All that #ifdef tends to clutter up the code. After som initial problem with a buggy card everything has worked flawlesly.

Quoted 10 lines · Pierre Ossman

Quoted 9 lines

I'm thinking that it would be better to not have the config option there and then re-add it late in the 2.6.14 cycle if someone reports problems which cannot be fixed. Or at least make it default to 'y' so we get more testing coverage, then remove the config option later. Or something.

Thoughts?

Quoted 3 lines

Removing it would be preferable by me. All that #ifdef tends to clutter up the code. After som initial problem with a buggy card everything has worked flawlesly.

OK.. Please send an additional patch for that sometime?

I'd rather not. The problem is that we have a host (thanks Intel) which is unable to report how many bytes were transferred before an error occurs. My fear is that doing anything other than sector by sector write will lead to corruption should an error occur.

However, I've no way to induce such an error, so I can only base this on theory.

It may work perfectly for the case when everything's operating correctly, but I suspect if you're going to do multi-sector writes, it'll all fall apart on the first error, especially on this host.

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?).

Quoted 8 lines · Pierre Ossman

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.

Quoted 9 lines

Quoted 8 lines

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?).

Quoted 11 lines

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

Quoted 8 lines

* 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...

Quoted 9 lines

Quoted 8 lines

* 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

Quoted 8 lines

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...

Unless the card is horribly broken it will not write sectors that cannot be transfered successfully. If there would be a transport error that goes undetected by the CRC we would just continue, believing that everything is peachy.

The scenario you're describing could show up in the case of a media error though. But that would mean that a sector went bad in an extremely short time, which isn't likely unless the wear leveling has gone crazy or the card is completely worn out. Either way the card is no longer useful.

Maybe the card is pretty close to going to crash, but... two disk successive disk errors still should not be cause for journal corruption.

[Also errors could be corelated. Imagine severe overheat. You'll successive failing writes, but if you let cool it down, you'll still have working media... only with corrupt journal :-)]
Pavel

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?).

Quoted 6 lines · Pierre Ossman

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?).

Providing the sectors are not finally completed to higher levels until they are written that works fine.