Můj systém doteď vypadal přibližně nějak takto (po vyčištění)

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        93M   26M   68M  27% /boot
/dev/sda3       9.8G  6.6G  3.3G  67% /
/dev/sda2       9.8G  3.5G  5.9G  38% /home
nealokováno v žádné partition 10G

předpoklkádám, že nový bude podobný, ale jak /, tak /home budou jednak větší, jednak budou mít každá kopii na tom samém disku, aby, pokud se něco stane, se jen přehodily a nějak se jelo na nepříliš starých datech

Pokud jsem pochopil wear leveling, tak pokud se na nějaký sektor zapíše, tak se starý sektor označí jako nevalidní (kandidát na smazání), z poolu smazaných sektorů se vybere ten, co byl použit nejméně častěji, data se zapíšou do něj a následně je namapován na místo (z pohledu OS), kam se zapisovalo.
Když není co dělat, tak se kandidáti na smazání na pozadí skutečně mažou a zařazujou do poolu.
Vymazání souboru z pohledu OS znamená, že se do nějakých jiných sektorů (Adresáře, FAT tabulky, nebo na novějších FS jiným obdobným způsobem) napíše, že sektory souboru už nejsou používané, ale ony pořád obsahuují staré hodnoty a SSD o jejich stavu netuší a má je za používané (a smazaný soubor jde zachránit)
Trim znamená, že se všechny bloky, které jsou z pohledu OS "prázdné", např. ty smazané soubory, nahlásí SSD jako "kandidáti na smazání" a SSD je časem promaže a zařadí do poolu použitelných sektorů. Přičemž ve FS se na tom místě objeví "díra", kam není namapováno nic a teprve až tam někdo zapíše, nebo odtamtud bude chtít číst, tak SDD udělá nějakou magii a namapuje tam cosi z poolu.

----

Tudíž po otrimování výše uvedeného disku zůstanou namapované pouze bloky o velikostech asi tak 26M + 6.6G + 3.5G (čili "used") a naopak bloky 68M + 3.3G + 5.9 G + 10G nebudou namapované, ale v poolu.
A při zápisu nového souboru do /home se použijou "nejlepší" bloky z poolu, ačkoli byly původně namapované do /, /boot, nebo nealokované oblasti (a nebo, ale nejen výhradně do /home)
Takže po řadě zápisů, mazání a trimování budou v poolu bloky z celého disku a mnohé si mezitím prošly několika namapováními do všech tří použitých partitions (/ /boot /home), protože SSD je nějaký FS ukradený a všechny bloky po smazání skončí na jedné hromadě a z té se pak bere, ať už se rozhodnu zapsat kamkoli.

Čímž není rozdílu, zda mám velkou "nealokovanou část", nebo velký součet prázdného místa na všech partitions (všechny ty bloky leží v poolu a čekají)

----

Pak je ještě vychytanější algoritmus SSD, který, pokud už jsou v poolu hodně "ošoupané bloky" tak do nich potají přepíše obsah souborů, co tam jsou už dlouho a jejich "neošoupané bloky" naopak vrazí do poolu.

----

A celé to může být prozděleno na nezávislé části, podle toho, jak to vyjde na konkrétní chipy (že si tohle dělá každý chip sám) a pak je lepší mít rozhozené partitions mezi chipy tak, aby pokud možno jich sdílely co nejvíc a tak se to rotovalo aspoň trochu mezi nima, aby jedna partition nebyla celá na "ošoupaném chipu" (a furt se do ní psalo a psalo) a jiná celá "neošoupaném chipu" (a jen se z ní četlo, ale nepsalo se do ní). Pokud ty partitions budou sdílet stejné chipy, tak alespoň část těch bloků bude cestovat mezi partitions a ošoupávat se na té používanější.

----

Protože ideálem je, když před havárií disku jsou už "ošoupané" všechny bloky a to tak, že stejně, nikoli, že se prodře jedna skupina bloků a ostatní budou netknuté.