[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ow to enable trim for an external encrypted SSD?

On 11/07, Alexander V. Makartsev wrote:
On 07.11.2017 03:01, Michael Stone wrote:
On Tue, Nov 07, 2017 at 02:20:56AM +0500, Alexander V. Makartsev wrote:
As I know SSDs are different in a way HDDs write their data. HDDs write
directly to the free block and are done. SSDs on the other hand will
have to
erase free block first to get it ready for writing and then write to
it. This
is because how NAND work. It's even worse, if a destination block has
some data
on it already and there is some data needs to be written onto it,
then SSD will
copy data already written, then it will fully erase destination
block, then it
will concatenate copied data with data to be written and finally will
merged data to the block.

This is mostly correct. The erasing is done in "erase block" size
units (much larger than disk blocks), while writing is done in
"pages", usually with hundreds of pages per erase block. So a 4kbyte
write might trigger a multi-megabyte erase if there aren't erased
pages available for writing. If an erase block has been partially
written, a write can go to an unwritten page without any additional
steps. In practice, most drive writes go immediately to already-erased
blocks, with the garbage collector erasing blocks while the drive is
idle (rather than actually reading, erasing, and writing for every
write). The drive then keeps track of which physical address is
associated with which logical address--that relationship changes as
blocks are written and rewritten, and it is not the case that the data
on the drive is physically ordered the same way it appears logically.

TRIM will erase blocks marked as deleted beforehand even if they are
not needed
for writing right now. This overhead is the reason that causes
increased drive
wear and decrease it's lifespan.

No, TRIM does not cause extra erases that wear out a drive. If you
don't TRIM blocks and mark them as unused, the garbage collector will
still erase blocks it doesn't need yet in order to have pages
available for future writes. (Either after the garbage collector
decides to launch a read & rewrite cycle to consolidate free space, or
when all the pages
in the erase block have been rewritten to a new erase block and the
old erase block is known to be empty) The only differences introduced
by using TRIM is that the drive can skip the possible read & rewrite
step, and the drive can increase the free pool so more new pages can
be written before a garbage collection is forced.
I still think there are scenarios where NAND ICs will suffer extra
writes, when TRIM is constantly used.
Also, can you explain what logic is behind this quote from "man 8 fstrim":
    "Running fstrim frequently, or even using mount -o discard, might
      affect  the  lifetime  of  poor-quality  SSD devices."

Poor quality FLASH RAM has lower MTBF, in some cases very much lower and given the NAND cluster failure mechanism death comes quickly.

I think I will find my answers in this huge article on wikipedia when I
wade through it eventually, should be quite interesting read:

With kindest regards, Alexander.

⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org


Jabber IM:dekkzz78@jabber.hot-chilli.net

Attachment: signature.asc
Description: PGP signature

Reply to: