On 05/08/2012 03:07 PM, Rafael Beims wrote:
Based on your response, would it be OK to implement the marker in the bbt as something like Liu Shuo suggested ('M', 'B', 'b', 't', 0) and then do the scanning as follows:
I'd leave the BBT marker alone, and have the migration marker be located elsewhere in the OOB that doesn't conflict with a BBT. That way the BBT code is untouched and the marker scanner only needs to consider one kind of marker.
Scan the bbt checking for the migrated flag as described. If we just find the default bbt marker, continue searching in the next block downwards to verify if we can find another marker indicating the migration (and completely independent of the bbt in this case).
Basically yes, except decouple it from the BBT. The BBT code works as always, and the migration marker code scans as described above. If they happen to be in the same block, fine -- the scanning code doesn't care either way; only the marking code needs to know which to do.
This second marker in this case would have to be written in a new block, or would it be OK to write it in a new page? It seems to me that a new block would be more appropriate, because you mentioned that a developer would like to erase the bbt sometimes, and that would imply the erasure of the entire block.
Right.
What are your thought's about this suggestion? What would be an appropriate marker for the second block? It seems that the usual (at least for the bbt) is a marker with a character sequence. Should I just create a different character sequence and write it in the oob of the first page of the next block to indicate "developer" migration?
I tend to prefer random numbers over short strings for magic numbers, to reduce the odds of collision, but whichever. Just pick an offset into the OOB that doesn't conflict with ECC or the BBT marker.
-Scott