MMC retry mechanism

MMC retry mechanism

[Madhusudhan]

Hi Adrian,

With respect to the below commit, It looks like currently the retry
mechanism only handles the READ path.

I wonder could a similar retry logic feasible for the WRITE path?

Regards,
Madhu

 

commit 6a79e391df295bd7c2aa1309ea5031f361c197fd
Author: Adrian Hunter <ext-adrian.hunter@nokia.com>
Date:   Wed Dec 31 18:21:17 2008 +0100

 

    mmc_block: ensure all sectors that do not have errors are read

    If a card encounters an ECC error while reading a sector it will

    timeout.  Instead of reporting the entire I/O request as having

    an error, redo the I/O one sector at a time so that all readable

    sectors are provided to the upper layers.

 

    Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>

    Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>

Re: MMC retry mechanism

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

On Fri, 4 Sep 2009 17:08:05 -0500
"Madhusudhan" <madhu.cr@ti.com> wrote:

> Hi Adrian,
> 
> With respect to the below commit, It looks like currently the retry
> mechanism only handles the READ path.
> 
> I wonder could a similar retry logic feasible for the WRITE path?
> 

The claim is that doing so can break some filesystem drivers (notably
the journaling ones). There has been several threads and patches about
this in the past.

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: MMC retry mechanism

[Madhusudhan]

> -----Original Message-----
> From: Pierre Ossman [mailto:pierre-list@ossman.eu]
> Sent: Sunday, September 06, 2009 9:21 AM
> To: Madhusudhan
> Cc: 'Adrian Hunter'; linux-mmc@vger.kernel.org
> Subject: Re: MMC retry mechanism
> 
> On Fri, 4 Sep 2009 17:08:05 -0500
> "Madhusudhan" <madhu.cr@ti.com> wrote:
> 
> > Hi Adrian,
> >
> > With respect to the below commit, It looks like currently the retry
> > mechanism only handles the READ path.
> >
> > I wonder could a similar retry logic feasible for the WRITE path?
> >
> 
> The claim is that doing so can break some filesystem drivers (notably
> the journaling ones). There has been several threads and patches about
> this in the past.
> 
Okay. Thanks for the info. I would like to read those discussions and the
patches, any reference? Or where do I look for them and any good way to
search such threads in general?

Regards,
Madhu

> Rgds
> --
>      -- Pierre Ossman
> 
>   WARNING: This correspondence is being monitored by the
>   Swedish government. Make sure your server uses encryption
>   for SMTP traffic and consider using PGP for end-to-end
>   encryption.

Re: MMC retry mechanism

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

On Sun, 6 Sep 2009 12:58:54 -0500
"Madhusudhan" <madhu.cr@ti.com> wrote:

> Okay. Thanks for the info. I would like to read those discussions and the
> patches, any reference? Or where do I look for them and any good way to
> search such threads in general?
> 

The subjects have been a bit unclear unfortunately, but you have a
couple of threads on LKML with the subject "mmc_spi: do proper retry
management in the block layer".

There is also an ancient thread with the subject "MMC performance",
which was back when I tried to tackle the issue originally.

There have been more threads over the years, but I'm afraid I don't
remember enough about them to find them again.

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: MMC retry mechanism

[Adrian Hunter]

Madhusudhan wrote:
> Hi Adrian,
> 
> With respect to the below commit, It looks like currently the retry
> mechanism only handles the READ path.
> 
> I wonder could a similar retry logic feasible for the WRITE path?
> 
> Regards,
> Madhu

>From my point of view, writes should never fail.  In theory, the MMC
should have enough reserved blocks to cover bad blocks for the
expected lifetime of the device.  It should then be just copying
and remapping to avoid having to return write errors.

Of course, a lot of cards probably don't do that right.  However,
I think maybe the block layer already retries failed writes.

> 
>  
> 
> commit 6a79e391df295bd7c2aa1309ea5031f361c197fd
> Author: Adrian Hunter <ext-adrian.hunter@nokia.com>
> Date:   Wed Dec 31 18:21:17 2008 +0100
> 
>  
> 
>     mmc_block: ensure all sectors that do not have errors are read
> 
>     If a card encounters an ECC error while reading a sector it will
> 
>     timeout.  Instead of reporting the entire I/O request as having
> 
>     an error, redo the I/O one sector at a time so that all readable
> 
>     sectors are provided to the upper layers.
> 
>  
> 
>     Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
> 
>     Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
> 
> 

RE: MMC retry mechanism

[Madhusudhan]

> -----Original Message-----
> From: Adrian Hunter [mailto:adrian.hunter@nokia.com]
> Sent: Monday, September 07, 2009 2:18 AM
> To: Madhusudhan
> Cc: linux-mmc@vger.kernel.org
> Subject: Re: MMC retry mechanism
> 
> Madhusudhan wrote:
> > Hi Adrian,
> >
> > With respect to the below commit, It looks like currently the retry
> > mechanism only handles the READ path.
> >
> > I wonder could a similar retry logic feasible for the WRITE path?
> >
> > Regards,
> > Madhu
> 
> From my point of view, writes should never fail.  In theory, the MMC
> should have enough reserved blocks to cover bad blocks for the
> expected lifetime of the device.  It should then be just copying
> and remapping to avoid having to return write errors.
> 
> Of course, a lot of cards probably don't do that right.  However,
> I think maybe the block layer already retries failed writes.
> 
What if there is a DATA CRC error during a write and the low level driver
reports the data.error as -EILSEQ. Will the block layer retry? I thought it
is supported only for the read through your patch.

Regards,
Madhu

> >
> >
> >
> > commit 6a79e391df295bd7c2aa1309ea5031f361c197fd
> > Author: Adrian Hunter <ext-adrian.hunter@nokia.com>
> > Date:   Wed Dec 31 18:21:17 2008 +0100
> >
> >
> >
> >     mmc_block: ensure all sectors that do not have errors are read
> >
> >     If a card encounters an ECC error while reading a sector it will
> >
> >     timeout.  Instead of reporting the entire I/O request as having
> >
> >     an error, redo the I/O one sector at a time so that all readable
> >
> >     sectors are provided to the upper layers.
> >
> >
> >
> >     Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
> >
> >     Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
> >
> >
>