No, if the datasheet says the block must be erased after one page write, issuing another page write before an erase is a good way to destroy some flash cells. A double write does not "save some cell transitions" but rather gives a good chance that that cell will not erase properly. This rules out any kind of incremental writes on this device, unless the firmware is really badly written. So "bank 32" is probably not (simple) validity flags.
Those "smoother grey sections" might be the validity/log-state data. Presumably the controller maintains tables in RAM and flushes them to the NAND array at shutdown, possibly with some kind of checkpointing scheme ("bank 32"? the "extra LPNs"?) embedded in the map pages with normal writes. That this is not exactly robust against power failure does not rule out its use in this drive — we already know that the drive is not robust against power failure!
Recopying live blocks as the "rewrite zone" approaches is what the early log-structured filesystems did, if I understand correctly. Trading a theoretical total life span for better wear leveling is not as absurd as it may sound — the SSD is dead as soon as it loses the last "extra" block anyway, no matter how many write cycles may remain on other blocks that are storing live data, since it can no longer provide its stated capacity and has no way to tell the host that the total space is dwindling, nor can most PC-ish (including Macs) filesystems handle storage devices that slowly dwindle away as SSDs do.
In reply to Re^10: Adding cols to 3d arrays - syntax
by jcb
in thread Adding cols to 3d arrays - syntax
by peterrowse
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |