On 12/19/2011 05:05 AM, Li Yang wrote: > On Sat, Dec 17, 2011 at 1:59 AM, Scott Wood <scottw...@freescale.com> wrote: >> On 12/15/2011 08:44 PM, LiuShuo wrote: >>> hi Artem, >>> Could this patch be applied now and we make a independent patch for bad >>> block information >>> migration later? >> >> This patch is not safe to use without migration. > > Hi Scott, > > We agree it's not entirely safe without migrating the bad block flag. > But let's consider two sides of the situation. > > Firstly, it's only unsafe when there is a need to re-built the Bad > Block Table from scratch(old BBT broken).
No, it's unsafe in the presence of bad blocks. The BBT erasure issue relates to how me mark the flash as migrated, not whether we migrate in the first place. > But currently there is no > easy way to do that(re-build BBT on demand), You scrub the blocks with U-Boot. It's not supposed to be *easy*, it's a developer recovery mechanism. > Secondly, even if the previous said problem happens(BBT broken). We > can still recover all the data if we overrule the bad block flag. How so? The bad block markers -- including ones legitimately written to the BBT after the fact -- are used for block skipping with certain types of writes. Without the knowledge of which blocks were marked bad, how do we know which blocks were skipped? > Only the card is not so good to be used again, That's a pretty crappy thing to happen every time you hit a bug during development. But again, that's irrelevant to whether this patch should be applied as-is, because we currently don't have any bad block migration at all. > however, it can be used > if we take the risk of losing data from errors that ECC can't > notice(low possibility too). Can you quantify "low possibility" here? Note that any block that *was* marked bad will have a multi-bit error from the marker itself, since it will be embedded in the main data area. > Finally, I don't think this is a blocker issue but a better to have > enhancement. No, it is not an enhancement. Processing bad block markers correctly is a fundamental requirement. And if anyone *does* start using it right away, then we'll have to deal with their complaints if we start checking for a migration marker later. Why is it so critical that it be merged now, and not in a few weeks (or next merge window) when I have a chance to do the migration code (assuming nobody else does it first) and add a suitable check for the migration marker in the Linux driver? -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
