On 11/04/2018 08:10, The Natural Philosopher wrote:
On 10/04/18 22:53, Vir Campestris wrote:
SSDs _do_ have one problem spinning rust discs don't, but you rarely
see it - if you write a _LOT_ of data they can run out of spare blank
space to write to, and they have to slow down while they clean a bit
more. The trim command (hi John!) is designed to let it know about
free space it can erase in advance.

This is more or less ********.

No, actually its a pretty good explanation.

SSDs can only write ENORMOUS blocks at a time.

Only if you think 2K to 16K is "enormous".

Typical page sizes on modern NAND flash devices range from 2K to 16K.
These are arranged in blocks of typically 128 or 256 pages per block.

So changing one bit on a file will, in the end, result in maybe 10K
bytes of write.,

10K is "unlikely" (in the extreme, think powers of 2)

For modern advanced format drives 4K is the standard sector size used by
the OS. So 4K is the smallest write size the OS will support. How that
maps to flash pages will depends on the physical page size of the
devices being used.

normally to a fresh block to minismise

The write will usually be to a fresh *page* (not necessarily a fresh
block). There are only limited modifications you can do to a page once
written, and you can't erase a single page at a time. So page writes are
typically to a fresh page within in a block. Only if there are
insufficient pages free in a block, then the drive *may* have to copy
all remaining valid pages from the current block to a new one. (and when
doing that, it would much rather not have to erase an existing used
block full of invalidated pages first)

wear which is all down to writes.

*Mostly* down to writes, however flash does suffer from a "read disturb"
characteristic that means the typical bit error rate for a block will
tend to increase with the number of page reads performed on it. Modern
flash controllers will also tend to keep count of this, and reallocate a
whole block of pages when the limit it reached.

This is not down to how MUCH data is written, but simply to how often it
happens.

That makes no sense at all if you think about it. A single 1MB file
write will take more flash write operations, than twenty 1K file writes
even though the latter is more "often"

In practive modern SSDS have a lot of cache RAM inside, to minimise
writes, and of course modern operating systems (even Windows) will also
cache writes in RAM.

Handy for random IO, but does not have much effect for larger sequential
writes. Ultimately you can only safely cache in RAM for a few seconds.

What this means is that lost of data does not slow down SSDS at all.
Only if all the cached writes in the disk and the operatinsg system get
full will the disk actually write anything at all, and SSD writes are FAST.

The writes are fast - when there is a free page in a block and / or a
free block to copy the existing block with modified pages into. The
difficulty comes when there are no free blocks and the drive then needs
to do a garbage collection and a block level erase. Its the block level
erase that is slow.

Newer drives can mitigate this somewhat with background garbage
collection - (that tends to help more on typical workstation workloads,
than server workloads).

Trim support at the OS level helps keep the drive aware of which pages
in any given block are actually valid. Thus it will reduce the time
taken to garbage collect, and also reduce the number of pages that need
to be copied to a new block when that time comes. That in turn reduces
the requirement for new writeable blocks, and hence reduce the number of
times a page erase operation will need to be done in the middle of a
disk IO operation.

Since they are done in HUGE chunks.

That's not necessarily the case, see above. The write speed for those
"huge chunks" will vary enormously depending on the circumstances. Its
why new fresh drives tend to perform better than more heavily used ones.



--
Cheers,

John.

/================================================== ===============\
| Internode Ltd - http://www.internode.co.uk |
|-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk |
\================================================= ================/