All Storable will do is provide a means for you to recover the @LPN and @PPN arrays quickly, after building them once. If they are as small as I expect, that will give you a large improvement in start-up time, and may allow you to examine less of the main image, therefore keeping more of your working data in the OS caches.
For a simple log structure, the scan on start-up could be a binary search to find the greatest distance between sequence numbers, but that would require that existing data be "moved out of the way" to allow the writes to always proceed sequentially. A cached map could also be in some other storage with better endurance characteristics separate from the main NAND array. Or the drive could depend on the host system's POST latency to hide the delays for the start-up scan, or store a few pointers sufficient to locate the first data that the host will want in only a few locations while storing the "rest" of the log index with more flexibility and continuing the scan while servicing the first few host requests.
Only a few bits set, with the vast majority clear, strongly suggests some kind of flags field. 128 bytes is 1024 bits, or (if I understand the structures you have found correctly) one bit for each 64KiB region in a group containing a "bank 32" field. If I recall correctly, NAND flash erases to all bits set, and most flash permits some number of write cycles, each only clearing additional bits, between erases. Hypothesis: only one of each set of duplicate LPN will have a corresponding bit set in "bank 32" if this is a validity field.
Finding the sequence number depends on guessing the drive's write sequence. For a simple log-structured filesystem that moves data to allow writes to always be sequential, this should be easy, since the sequence numbers will monotonically increase with one break somewhere on the media. Unless the sequence numbers are not write sequence, but something derived from power-cycle count, since the drive could keep its actual write count in the controller's RAM and reconstruct this from the NAND array on start-up. That would explain the repetition, if it is some kind of session ID.
How full was the filesystem and did the host use the TRIM command to release blocks? If the NAND array was mostly (or entirely) allocated, I would expect very little variation in an "in-use" or "valid data" field across the disk.
In reply to Re^4: Adding cols to 3d arrays - syntax
by jcb
in thread Adding cols to 3d arrays - syntax
by peterrowse
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |