The purpose of TRIMing is to get erase pages as soon as possible back into the allocation pool. These pages can then be erased (as needed) to increase 'write' performance and have enough allocateable free pages for upcoming writes (which are actually read, modify, erase, write, ops, while TRIMing helps in prefetching the very expensive erase op). An erase block is a continuous block of sectors. As long as not all FS blocks covering this erase block were trimmed, the advantage of trimming is anihilated (for obvious reasons). As an example, assume a 64k erase page size and 4k FS-blocks. Now erase a big file (i.e. 1GB), while only trimming 1% of the covered space randomly. The probability that you'd TRIM multiple sets of 16 continuous FS blocks (if we assume proper alignment) when only trimming 1% of the 1GB file is next to zero. If the FS blocksize is smaller and the erase page size bigger, it's even worse. Sidenote: An erase page size of 512KB is not really uncommon for MLC NAND. As Arno already said, all you can do is weigh out leakage versus performance. On Sun, April 15, 2012 18:55, alban bernard wrote: > --- On Sun, 4/15/12, Sven Eschenberg <sven@xxxxxxxxxxxxxxxxxxxxx> wrote: >> That would render TRIMing completely >> useless anyway and you could as well >> turn it off. > > Not really if there are enough TRIMed blocks before block writes occur. > There lies the purpose of a "smart" layer that will be responsible of > TRIMing blocks in a certain amount of the total space: a kind of TRIMed > block buffer that smooths writing zeroes and spreads them among the device > the "crypto" way. > > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
