3 ms·

Not got links to details, but you can think about wear levelling at two levels. The first and most obvious, is wear levelling between blocks of flash memory. H

Not got links to details, but you can think about wear levelling at two levels. The first and most obvious, is wear levelling between blocks of flash memory. Here the SSD controller tracks how often it erases blocks of memory which are probably tens to hundreds of bytes large, and tries to keep those counts nice and even. You’re probably already aware of that type of wear levelling. But wear levelling across multiple blocks means that there’s nothing tracking how often each cell within a block of memory is being written to and erased, because that depends on exactly what data is written into the block. So if you’re writing data that has a repeating pattern that’s a multiple of your block length, then specific cells within that block will be written to more often than others. This impacts both the wear of the individual cells, but probably also write quality as well, because have two cells next to each other with vastly different stored values almost certainly adds noise when reading again (nature hates a gradient). You can’t track wear on a per-cell level, because that would require an extreme amount of memory just to store counters, which could be better used to store data. But what you can to is transform the data your writing into “random” data to remove any patterns and produce even wear. Additionally the randomness will also reduce the variance in stored values between adjacent cells, improving write quality. So encrypting the data provides a bunch of very useful adjacent benefits for a very small cost. Encryption algos like AES are deliberately designed to very high performance on extremely low power, memory constrained devices, and typically have a pretty low transistor count for dedicated crypto silicon. So using strong AES encryption in an SSD is pretty much a no-brainer. You get improved reliability (because better wear levelling), improved performance (because writes are more successful), and feature you charge extra money for (on device full disk encryption).

vlovich123 4y ago
I'm not sure I follow. Am I correct in understanding that you're saying that if a block has some pattern, then overwriting that block with the same pattern will result in no extra wear on that block but neighboring blocks might overwrite and therefore would have worse wear. Thus encryption smears it out and ensures that you have consistently worst case wear always and that somehow improves reliability? I'm assuming the reason this works is because the underlying block that gets written isn't the same one that has the old data and thus the probability of overwriting with the same data is low because the encryption key for a given write is somehow derived from block offset + length to make sure that a duplicate pattern for a given block will still encrypt differently? If I understood that properly, this feels like a lot of complexity for unclear gain (not seeing how it improves write leveling vs at best downgrading the best case / average case to the worst case) and I haven't found any papers online. Is this mechanism something you actually first hand building or something you remember reading from some tech newspaper? Would love a primary source here.
- avianlyric 4y ago
  > Am I correct in understanding that you're saying that if a block has some pattern, then overwriting that block with the same pattern will result in no extra wear on that block > I'm assuming the reason this works is because the underlying block that gets written isn't the same one that has the old data and thus the probability of overwriting with the same data is low because the encryption key for a given write is somehow derived from block offset No, this has nothing to do with writing the same data to the same blocks, but rather how you handle a continuous stream of data being written (and eventually overwriting older data) to the drive over very long periods of time. You should assume that physical location of your data bears zero correlation to the address to write it to. The SSD controller will always redirect it to least worn available block. In SSD it’s reasonable to assume that the flash memory can be erased and written at a more granular level than you would want to track for wear levelling purposes (because extra granularity cost more money). So writing repeated patterns of data to a disk that align with the wear levelling block size will result in some parts of your flash memory being written and erased more often. But this unevenness is too granular for the wear levelling algorithm to track and compensate for. Encryption removes the need to track more granular wear patterns because it ensures that every single bit of your flash memory is going to see very similar write patterns. Additionally there’s an entirely separate aspect, which is that NAND flash is a physical storage medium, and economics mean manufacturers want to squeeze every last ounce of storage out of their silicon. This means pack flash cells physically close to each other, and storing multiple values in each cell. The consequence is that activity in one cell can cause changes in adjacent cells, if those changes are large enough value of a cell will change corrupting the stored data. By encrypting the data you can eliminate the possibility of extreme edge cases occurring which have a high risk of data corruption. At better place to observe these types of issues is to look at RAM, and Row Hammer attacks. The basic principles are the same, even if the precise physical interactions are a little different.

vlovich123 4y ago

I'm not sure I follow. Am I correct in understanding that you're saying that if a block has some pattern, then overwriting that block with the same pattern will result in no extra wear on that block but neighboring blocks might overwrite and therefore would have worse wear. Thus encryption smears it out and ensures that you have consistently worst case wear always and that somehow improves reliability? I'm assuming the reason this works is because the underlying block that gets written isn't the same one that has the old data and thus the probability of overwriting with the same data is low because the encryption key for a given write is somehow derived from block offset + length to make sure that a duplicate pattern for a given block will still encrypt differently? If I understood that properly, this feels like a lot of complexity for unclear gain (not seeing how it improves write leveling vs at best downgrading the best case / average case to the worst case) and I haven't found any papers online. Is this mechanism something you actually first hand building or something you remember reading from some tech newspaper? Would love a primary source here.

avianlyric 4y ago
> Am I correct in understanding that you're saying that if a block has some pattern, then overwriting that block with the same pattern will result in no extra wear on that block > I'm assuming the reason this works is because the underlying block that gets written isn't the same one that has the old data and thus the probability of overwriting with the same data is low because the encryption key for a given write is somehow derived from block offset No, this has nothing to do with writing the same data to the same blocks, but rather how you handle a continuous stream of data being written (and eventually overwriting older data) to the drive over very long periods of time. You should assume that physical location of your data bears zero correlation to the address to write it to. The SSD controller will always redirect it to least worn available block. In SSD it’s reasonable to assume that the flash memory can be erased and written at a more granular level than you would want to track for wear levelling purposes (because extra granularity cost more money). So writing repeated patterns of data to a disk that align with the wear levelling block size will result in some parts of your flash memory being written and erased more often. But this unevenness is too granular for the wear levelling algorithm to track and compensate for. Encryption removes the need to track more granular wear patterns because it ensures that every single bit of your flash memory is going to see very similar write patterns. Additionally there’s an entirely separate aspect, which is that NAND flash is a physical storage medium, and economics mean manufacturers want to squeeze every last ounce of storage out of their silicon. This means pack flash cells physically close to each other, and storing multiple values in each cell. The consequence is that activity in one cell can cause changes in adjacent cells, if those changes are large enough value of a cell will change corrupting the stored data. By encrypting the data you can eliminate the possibility of extreme edge cases occurring which have a high risk of data corruption. At better place to observe these types of issues is to look at RAM, and Row Hammer attacks. The basic principles are the same, even if the precise physical interactions are a little different.