4 ms·
This doesn’t account for the write amplification factor, which is quite unlikely to be 1 with a naive wear leveling implementation and the most brutal write wor
by mgerdts 4y ago
This doesn’t account for the write amplification factor, which is quite unlikely to be 1 with a naive wear leveling implementation and the most brutal write workload.
- adgjlsfhk1 4y agonote that there are data structures (eg b epsilon trees) that can guarantee a write amplification factor of log_b(disk size) for very large b (over 1000). this means that if you are willing to sacrifice a small amount of sequential read speed, you can guarantee write amplification of no more than 4 (with a few mb of RAM).
- mgerdts 4y agoI've added [1] to my reading list. Do you have suggestions for others that relate specifically to WAF? 1. http://supertech.csail.mit.edu/papers/BenderFaJa15.pdf http://supertech.csail.mit.edu/papers/BenderFaJa15.pdf
- adgjlsfhk1 4y agoThe TLDR is that the design of b^e means that (other than the root node which you can store in RAM), you never need to write in chunks less than b^e (smaller writes get batched and pushed down the tree only when you have that much data to write to a child node). With the typical, e=1/2, you can set b=blocksize of SSD^2. This means that any small write will turn into 1 write per depth of the tree, and each of those writes will be writing a full block of data (so the maximal WAF is the depth of the tree). Also, for bigger writes, you can just write to the bottom directly, so this ends up working out such that for large sequential writes, you get a WAF of 1, and for small/random writes, you get a WAF of d.