Re: mtd nand erase and bad block

[Angus CLARK <angus.clark@st.com>]

On 06/27/2012 10:54 AM, Artem Bityutskiy wrote:
> On Mon, 2012-06-18 at 10:34 +0100, Angus CLARK wrote:
>> On 06/05/2012 01:17 PM, Artem Bityutskiy wrote:
>>> On Fri, 2012-06-01 at 17:54 +0300, Shmulik Ladkani wrote:
>>>>
>>>> My personal preference would be:
>>>> 1. A new ioctl (MEMSCRUB?)
>>>> 2. debugfs flag, PER MTD PART (slightly safer than your global flag)
>>>> 3. global debugfs flag
>>>>
>>> Yes, I guess option 1 is the best I think. Option 2 needs too much work.
>>
>> Are you ok with the name MEMSCRUB?  I know previously you have objected to this
>> name, since it might get confused with UBI scrubbing
>> (http://lists.infradead.org/pipermail/linux-mtd/2010-September/032031.html).  In
>> fact, the conclusion of that thread was to add an extended erase IOCTL, with a
>> 'flags' parameter to capture options such as erase bad blocks.  Would this be
>> the preferred method (it didn't seem to go anywhere last time), or is 'MEMSCRUB'
>> with the existing erase_info_user64 structure acceptable?
> 
> I think Shmulik had a good point - scrubbing is not only about erasing,
> but also about changing the BBT. So a separate ioctl makes more sense.
> As for the name, we could name it MEMBBSCRUB, I guess?
> 

There may be others, but the two use-cases I have for erasing blocks marked as
bad are:

1. Restore the status of a block known to be good, but marked as bad.  The block
may have been marked bad deliberately, for test purposes, or it may have been
incorrectly identified as bad due to "alien" data from a previous driver/ECC
scheme clashing with the OOB BBM.

2. Erase the Flash-resident BBTs.  These blocks are reported as bad to prevent
accidental write or erase operations.  However, one might want to erase the
BBTs, either to test the OOB BBM scanning and BBT rebuild on next reboot, or
prior to changing driver and/or ECC scheme.

For case 1, it makes sense to update the BBTs at the same time.  At present, I
have to scrub the block in question, scrub the BBTs, and then reboot to force a
rescan/rebuild of the BBTs.  (This is fairly simple to do, but does risk loosing
information about blocks that have gone bad through wear, unless invoking the
"mtd: nand: write BBM to OOB even with flash-based BBT" patch.)

However, for case 2, I just want to force the erase operation so I can wipe the
BBTs and return the device as close as possible to its original state.  We could
put some logic in the kernel, "if 'MEMBBSCRUB" on BBT blocks, do not
update/rewrite BBTs", but I think this "policy" decision would be better handled
in userspace.

At the risk of repeating the discussion in
http://lists.infradead.org/pipermail/linux-mtd/2010-September/032031.html, how
about adding the MEMSCRUB IOCTL for erasing blocks marked as bad (I have the
kernel and mtd-utils patches available), and then adding 'MEMSETGOODBLOCK' for
updating the BBTs and/or OOB BBM?

Cheers,

Angus