Christoph Anton Mitterer wrote: > Nevertheless,... with an SSD "erasing" only makes sense via TRIM, Not really. An SSD has to erase a whole erase-block (thought to be 512kB on the Intel drives) whenever it can't satisfy a write from a currently-erased device block (512 bytes or 4k or whatever). This is how flash works: you have to erase before writing anything (unless the bits are all zero already), and the smallest erase unit is >1 block. So other blocks from the target erase-block must be copied to some other physical location, or they'd be lost. This has nothing to do with intentional discarding of data from the FS layer via TRIM. (TRIM does help the SSD decide what other erase-groups it can possibly use when it has to overwrite. But AIUI, that's all. Note also that AFAIK the device doesn't have to actually *do* an erase on TRIM, though I could be wrong on that. That might be an interesting performance-versus-security tradeoff experiment, actually...) If you can force your upper-level data transformations (device mapper, possible raid, dm-crypt, filesystem, user programs running on the FS) to happen in units of the erase block size, you can make write performance a lot more predictable. Mind you, I don't know if it's possible to do that, especially at the FS layer and above. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
