Ross Younger wrote:
Jonathan Larmour wrote:
Given you are assuming partial-page writes, I think you can do
something more intelligent here [...]
When you write a new revision of a block, you mark the previous one
dead by overwriting it with a partial write (without erasure).
I think there are too many overwrite-forbidding chips around for this to
be a goer (including, inter alia, the one on my desk).
MLC?
When I talked about partial-page reads and writes, I meant only that the
NAND library would cope with being asked to read or write a non-integral
number of pages; that it would do the right thing in terms of how many
bytes it actually sent to the chip and computing/checking ECC.
Ah. I thought you meant a separate write for the ECC (although it's true
that I half-wondered why).
> I should note though that multiple writes are not supported on newer MLC
> NAND flash. This could be an issue as this class of NAND may become more
> common. Perhaps in that case an obsoleted block can just be erased
> immediately.
We could indeed have a two-bit serial number per logical block and use
that as a distinguisher, erasing the old copy immediately (hence the
older serial number wins). However, dropping the master serial number
means we can no longer detect which was the last block to be written (to
the device as a whole), which I was relying on in order to set up my
next-write-here pointer.
You could choose one randomly (the seed being the current usage pattern,
to prevent repetition).
- That frees up space which we can use for potential optimisations. In
particular, the common use-case we are envisaging is wholly sequential
reads of fairly large images. So we could use 2 bytes to point to the
next block in the logical block chain. This is very useful if most use
is sequential.
I'm not sure whether this gets us much. NAND blocks are commonly so
large that I think that many applications will only ever be using a
small number at a time?
Hmm, I think I was getting things a bit mixed up, since you had been
talking about OOB data for each block, and that made me sometimes think
about pages instead of blocks. But on rereading more carefully you do say
about using the OOB data of the first page of each block. Since blocks are
of the order of 256Kbytes then indeed the majority of the time we'd only
need to consider up to say 8 blocks. So I think my concerns about scanning
the medium diminish markedly.
Jifl
--
------["The best things in life aren't things."]------ Opinions==mine
