Hi Keith, thanks for the heads up on thermal stress.
The next factor is the internal write multiplication factor. Lets say you > have a device which is divided into 2 MB blocks. And you update 1 sector > (512 bytes) somewhere in this block. The device must (a) read out the > entire 2MB block (b) update the data within the block then (c) re-write a > new 2 MB block to replace the old. That I don't get. Are you sure about that? My understanding from what I've been reading was that the technology behind SSDs would force you to *erase* 2 MB blocks but also allow you to *write* e.g. 4KB pages. In other words, I was expecting the SSD controller and/or the filesystem to be smart enough to cleverly allocate and move pages around within the available blocks. So if a 2MB-block is made of 512 4KB-pages, just overwriting the same 4KB page 512 times will only cause one block erasure (or something in that order of magnitude), not 512. If that is correct, my conclusion would be that you should always write in multiples of the page size (e.g. 4KB), assuming you somehow get to know that value. Perhaps you're actually saying the same thing in the following paragraph? > This places a heavy erase-reuse of blocks containing things that are > updated frequently (like directory blocks). In many cases the storage > controller will compensate for this fact by allowing blocks to have "holes" > and having the "hole" written as a component piece of a block that also > contains other changed blocks and the block containing the "hole" is only > recovered by background wear leveling. This means that there needs to be a > table mapping "logical blocks" to "physical blocks" and that must be stored > somewhere as well, and is even more volatile than the data blocks > themselves (so it is usually stored in RAM and only periodically backed up > to the persistent flash storage). Additionally, data may be deleted > without being overwritten and this is optimized by use of TRIM which allows > the storage controller to be aware of what data is does NOT need to copy. > Thank you! Gerlando _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
