[mythtv-users] Low Power System

[Simon Hobson]

James Linder <jam at tigger.ws> wrote:

>> If you're going to leave 20% of your drive un-partitioned you probably
>> don't need to worry too much about TRIM. You're always going to have
>> 20% spare sectors to swap things into.
>> 
>> It's certainly much less important that sorting out unnecessary logging.
> I seek words of wisdom:
> 
> If you *do not* leave some un partitioned, space implication is that the file system will mark and not use sectors as they get used-up.
> What happens when you delete a file whose inode is used-up. As I understand the 1 indirect inode is fixed in place the 2 and 3 indirect inodes could be relocated
> [pointer to a sector of inodes, pointer to a sector of pointers to inodes].

I don't understand what you are asking here, sorry.

But, my understanding of how SSDs work is this - and I'm ready to be shot down if it's wrong :
They always (even if you think you are using the whole drive) keep a pool of "spare" chunks - I'll call them that to avoid confusion with unix blocks or disk sectors. And in the background, it will erase these spare chunks to form a pool of empty chunks.
When you write something to the SSD, unless it happens to be to a chunk that's already empty (as may be the case when it's new and you are first putting data on it, then it : reads the rest of the chunk your data will be a part of, inserts your block/sector of data, writes out the modified chunk to a spare empty chunk, then remaps that chunk to replace the original.
That leaves it with a spare non-empty chunk which is then put in the queue to be erased in the background.

Thus for light write duty, write speeds will always be quick.

As people have observed, if you throw a lot of writes at the SSD quickly, then it runs out of spare empty chunks. Once this happens, write performance drops through the floor as the writes must now wait for a chunk to be erased before it can be written.

The trick of leaving part of the drive unused is to enlarge the pool of empty chunks - since the drive doesn't need to map a chunk that's never been used, and so this space can effectively be added to it's spare pool.

TRIM takes things a step further. It provides a mechanism for the OS to tell the drive (when it deletes a file) : these sectors are now spare even though they have data in them. The drive can then add the chunks containing the sectors to it's list of what's unused - I don't know how granular this is, ie whether it can keep track of chunks that are partially unused.
So TRIM *shouldn't* have any effect whatsoever on time taken to delete a load of files - simply because all it does is tell the SSD that a load of sectors are now unused. What is should do, is enable the drive to keep a larger pool of erased chunks in hand.

Also, I believe the drives can write fresh data in a partially used chunk - it can flip bits one way, but not the other.
So where the drive knows that part of a chunk is unused, it can (as a background task) read the chunk, zero out the unused space, write it to a spare empty chunk, and remap it (and then erase the previously used chunk). When it needs to write data in the empty space, it can now just read-modify-write the chunk in place - reducing the need to read-modify-write to somewhere else-remap.

Given all this, I actually don't understand the performance penalty noted in the link posted further back in the thread. Because TRIM shouldn't have any measurable performance penalty at the time of deleting a file - it should just have a performance benefit to writes generally.

And BTW - this swapping around of chunks is not just for performance reasons - it allows the drive to map chunks around for wear levelling. You can keep writing one sector all the time, and internally this will cause writes to many different chunks of flash memory. This is the case for SSD drives, but not typically for things like flash memory cards unless they are "a bit better than average" internally.