laptop advice time...

[Lennart Sorensen]

On Fri, Aug 23, 2013 at 10:41:28AM -0400, D. Hugh Redelmeier wrote:
> I would have thought that 2 and 3 do the same job in different ways.
> 2 acts earlier, so 3 would be redundant.
> 
> I admit that I don't really understand the subtleties of TRIM on
> different abstraction layers (real disk vs virtual decrypted disk).
> 
> With luks, is there a simple one-to-one correspondence between encrypted 
> and decrypted blocks?
> 
> I would be surprised if discard and fstrim are both useful: one or the
> other should do the job.  I don't know which is better, but some
> advocate fstrim over discard and I don't remember any advocating
> discard over fstrim.

My understanding is that using fstrim from cron regularly is more
efficient since you just scan the filesystem for free space and do large
trim operations.  Using discard means every time a block is erased that
block is also trimmed, which on some SSDs cause the SSD to do a garbage
collection sweep which can take a while.  At least that's how I
understood it.

> | From: Lennart Sorensen <lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org>
> 
> | TRIM helps performance, but other than that should not actually affect
> | the lifespan of the device.
> 
> I don't think that that is correct.  TRIM avoids useless copying, and
> all writes are likely to cause SSD wear.

TRIM tells the SSD that this block is deleted, and can be erased and
put in the free pool.  After all when you delete a file, the blocks are
marked free in the filesystem, but you don't go overwriting with zeroes
or anything in general, and the disk has no idea that the block is never
going to be read again.  That is what TRIM is for.  Let the disk know
that you will never want to read this block's data again and that it can
be erased.  If you do ever read it, you don't care what the contents is
(so it will probably be all zeroes or all ones), until you actually
write to it again.

Having more erased blocks around makes it easier for the SSD to write
new data, since new data must be written to an erased block (perhaps
after reading some of the existing data in the old block that is being
"updated").  Once the data is written to a new block and it is mapped
to the logical block number, then the old block is added to the blocks
to be erased and placed in the free pool.  So by telling the SSD that
the block can be erased and placed in the free pool, you give the SSD
more space to do writes to, before it must go and spend time erasing
blocks that have old data in them.

SSD's use NAND flash in general, which can only be written to after
the whole block is erased.  Erasing sets all the bits to 1, and writing
clears some of those bits to 0.  So you can only set bits to 1 if you
do the whole block, while you can set bits to 0 individually.

TRIM does not eliminate the read/modify/write cycle that writes smaller
than a flash block require, it simply allows it to happen faster because
the pool of already erased blocks is likely to be larger so bigger writes
can be done in a row, before garbage collection and erasing must be done.

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists