On 2023-02-16 at 08:10, Nicolas George wrote: > The Wanderer (12023-02-16): > >> filesystems et cetera aligned to physical blocks, because physical block >> size defines the minimum size that can be erased (and, therefore, >> overwritten) in any given operation, > > This is true. Note: erased, not written. My understanding is that in order to write data into a block which has already been written, the drive controller must erase the entire block and write it all again. Therefore, except for the narrow case of writing into a block which has never before been written, every write on a SSD *is* an erase+write operation. >> and therefore impacts both wear >> rates and write speeds in what is potentially a very serious way. > > This is not a logical consequence. > > You are assuming that if a block of flash memory contains B sectors, > then the block number b will contain the sectors from number B×b > included to number B×(b+1) excluded. > > 0 1 2 > ┌───────────────────┬───────────────────┬───────────────────┐ > ┌────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┬────┐ > 0 1 2 3 4 6 7 8 9 10 11 12 > > This is how it works for physical / logical sectors, but not for blocks > of flash memory. > > With flash memory, if you want to rewrite a sector, you can only write a > blank sector. > > So: you read the whole block, blank it, then re-write all the other > sectors and your updated sector? No, definitely not, that would be > terrible. That is exactly what I've always been told *does* happen, ever since first reading about how SSDs et cetera work, more than a decade ago. This is the first time I've seen a suggestion to the contrary. > What happens is, very schematically: the controller finds an unused > sector in a blank block (either one that has never been used or one that > has been recently erased), it writes the new data there, then updates > its remapping table to mark the old data obsolete and where the new data > is. That's an interesting design approach. Given that I've never seen it mentioned before, I imagine it must be comparatively recent as SSD controller designs go. I would not want to assume that every SSD does it; I would certainly not want to assume that there will always be such a block available, although in practice there *almost* always will be. I'm also not sure that I'd have chosen to take the trade-off of that added complexity for the presumed added performance and lack of need to keep track of block size handling. Additionally - I haven't thought it all the way through, but at a glance I'm wondering if this wouldn't also result in more total writes (thereby reducing the effective drive lifespan) than the way I've always been told it works; initial analysis isn't finding a way that it would, but I'm not sure I trust my initial analysis to have it right. > I do not know how the remapping table is kept; probably some kind of > journal with RAM caching. And of course, there are optimizations and > trade-offs: if a block contains only obsolete sectors except for a few > ones, it might make sense to move these non-obsolete sectors to a new > block to have the old one ready for erasure. I suspect constructors keep > what they do exactly as trade secrets. > > But the short of it is that it does not make sense to worry about > alignment, because even if you do, there is no guarantee that the first > sector of your partition will be the first sector of its block, and even > if it is it might not be tomorrow after it has been rewritten by the OS, > i.e. reallocated by the controller. So, if this is correct, we have both less understanding and less control of where and how data is stored on the drives than we think we do. Even if/though it's not common to *need* such, that hardly seems like it can possibly be considered a good thing. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature