public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <maximlevitsky@gmail.com>
To: Alex Dubov <oakad@yahoo.com>
Cc: joern <joern@logfs.org>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: RFC: [PATCH V3 0/9 Integration of SmartMedia/xD into mtd subsystem
Date: Fri, 15 Jan 2010 11:18:19 +0200	[thread overview]
Message-ID: <1263547099.3247.16.camel@maxim-laptop> (raw)
In-Reply-To: <507734.29595.qm@web37605.mail.mud.yahoo.com>

On Thu, 2010-01-14 at 18:01 -0800, Alex Dubov wrote: 
> > > 
> > > Still bear in mind that FTL can destroy data,
> > especially if your flash
> > > card is worn out.
> 
> I sort of worry about this particular issue.
> 
> When I was doing my FTL, handling of bad blocks was one
> of the major (if not the primary) implementation problems.

This is more or less an disclaimer.
If I compare what windows driver does versus mine, I do much more
checking.

My FTL maybe is a bit erase happy, as it tries to erase blocks it found
errors that likely not result of wear but a cut in the power.


Here is a summary of algorithm that I do for scanning:


1. Test is block is marked as bad.
Here I don't cheat and read whole block, because data_status could be
set for a specific sector.
However this is a bit slow, because it causes oob of all sectors to be
read.

2. Read LBA of each sector. Due to mtd layering this makes me read oob
of each sector again.
If I find a sector with lba that can't be read or a sector that has a
different lba that first, I erase the block. This I might revisit.


3. Update the LBA->physical table. If I see that this LBA is taken, I
check again both candidatures, and this time I also read the sector
contents, which will fail if there are unrecoverable ECC errors.
If one of sectors turns out bad this way I pick the other one, if not I
just erase one of the sectors (this is likely a powerfalll situation
too)


Every time an erase is made, hardware will return errors if failed 
When this happens I mark block as bad.


Best regards,
Maxim Levitsky

      reply	other threads:[~2010-01-15  9:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-12 19:28 RFC: [PATCH V3 0/9 Integration of SmartMedia/xD into mtd subsystem Maxim Levitsky
2010-01-12 19:29 ` [PATCH 1/9] MTD: call remove notifiers before removing the device Maxim Levitsky
2010-01-12 19:30 ` [PATCH 2/9] MTD: create lockless versions of {get,put}_mtd_device Maxim Levitsky
2010-01-12 19:31 ` [PATCH 3/9] MTD: blkdevs: make hotplug work Maxim Levitsky
2010-01-12 19:32 ` [PATCH 4/9] MTD: make mtdtrans thread freezeable Maxim Levitsky
2010-01-12 19:33 ` [PATCH 5/9] MTD: export few functions from nand_base.c Maxim Levitsky
2010-01-12 19:34 ` [PATCH 6/9] MTD: common module for smartmedia/xD support Maxim Levitsky
2010-01-12 19:35 ` [PATCH 7/9] MTD: add few workarounds to nand system for SmartMedia/xD chips Maxim Levitsky
2010-01-12 19:36 ` [PATCH 8/9] MTD: Add nand driver for ricoh xD/SmartMedia reader Maxim Levitsky
2010-01-12 19:37 ` [PATCH 9/9] MTD: Add new SmartMedia/xD FTL Maxim Levitsky
2010-01-14 23:27 ` RFC: [PATCH V3 0/9 Integration of SmartMedia/xD into mtd subsystem Maxim Levitsky
2010-01-15  2:01   ` Alex Dubov
2010-01-15  9:18     ` Maxim Levitsky [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1263547099.3247.16.camel@maxim-laptop \
    --to=maximlevitsky@gmail.com \
    --cc=joern@logfs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=oakad@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox