Hikari: SSD a velký diskový úklid

2.8.2011 22:07 | Přečteno: 2684× | Linux | | poslední úprava: 2.8.2011 22:07

Konečně mi vyšel plán pořídit si do Hikari SSD jako systémový disk. Má volba padla na 80GB Intel řady 320, ač Intel nešel s cenami nové generace tak dolů, jak se očekávalo. Následuje popis instalace a čarování v Arch Linuxu a proměny Hikari z víceuživatelského desktopu v desktop určený výhradně pro mě.

Instalace SSD

Užitečné informace: SSD na ArchWIKI, GPT na ArchWIKI, GRUB 2 na ArchWIKI, LUKS na SSD a znalosti LVM a LUKS v rozsahu předchozího povídání o Hikari a Kawagiri.

Instalace hardwaru

Tak nejprve nějaké to hrabání se v železe. Vcelku nic obtížného, zapojení dvou konektorů, poté co jsem ze starých zásob vyhrabal SATA kabel – k OEM balení se překvapivě nedodává vůbec nic (to je ironie…) Přišroubování 2,5" disku do 3,5" pozice – tady to začíná být těžké… Nakonec jsem zvolil přišroubování dvěma šrouby (také ze starých zásob) k jedné straně slotu – disk je lehký. Mentální poznámka: Zkontrolovat po nějaké době, zda to nedělá bordel. Nyní přichází ke slovu BIOS: Nechceme přece, aby se stroj snažil bootovat z prázdného disku…

Vytváření diskových oddílů

Původní představa Hikari počítala s tím, že stroj bude intenzivně víceuživatelsky využíván, takže jsem se rozhodl pro řešení LUKS nad LVM doplněný o pam_mount. Svého času byl také Hikari využíván na hraní her přes Wine, opět více uživateli. Shrnuto se při běžném startu odemykalo cca 7 LUKS oddílů, což mělo patřičné dopady na rychlost resp. pomalost startu. Na hraní her a vyžívání se více uživatelů je tu však už nějakou dobu Haku, takže LUKS nad LVM ztrácí smysl. Hurá tedy do implementace osvědčeného schématu z Kawagiri: LVM nad LUKS.

Vzhledem k tomu, jak vypadají vnitřnosti SSD – přečtěte si pár článků o SSD na AnandTechu –, se doporučuje zarovnat diskové oddíly. ArchWIKI na to doporučuje použít GPT namísto MBR. Pro bootování z GPT pak GRUB2 potřebuje trošku specifičtější rozložení diskových oddílů – chvíli jsem uvažoval o syslinuxu, ale pak jsem si řekl, že by to bylo příliš novot naráz. LUKS pak stále ještě vyžaduje nešifrovaný celý /boot oddíl. V nástroji gdisk tedy vytvoříme něco následujícího (všimněte si, jak gdisk oddíly hezky zařezává):

Command (? for help): p
Disk /dev/sdb: 156301488 sectors, 74.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 919BFD80-A73B-4A00-B805-F080B95886F9
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 156301454
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            4095   1024.0 KiB  EF02  BIOS boot partition
   2            4096          208895   100.0 MiB   8300  Linux filesystem
   3          208896       156301454   74.4 GiB    8300  Linux filesystem
    

Megový oddíl je ta spešl vyfikundace pro GRUB 2, 100 MB je na /boot a zbytek na šifrovaný LUKS oddíl. Ten vytvoříme se speciálním parametrem, aby také zařezával, i když možná, že už to nový cryptsetup umí sám:

[root@hikari ~]# cryptsetup -c aes-xts-plain -s 512 -y  luksFormat --align-payload 8192 /dev/sdb3
    

Následuje LVM, tentokrát se snažím o něco univerzálnější pojmenování. I zde jsou použity parametry pro správné zařezávání oddílů, i když by je opět nové lvm mohlo umět automaticky. Vzhledem k tomu, že na stroji je nepříliš dostačujících jeden a půl GB RAM, vytvářím také swap oddíl. O minimalizování zápisů na SSD jsem četl poměrně rozporuplné články. No upgrade Hikari na něco s mnohem více RAM je v plánu, navíc SSD má dobrý „controller“ a dost volného místa na „wear-levelling“, tak uvidíme.

[root@hikari ~]# pvcreate --dataalignment 8192 /dev/mapper/hikari_ssd_luks 
[root@hikari ~]# vgcreate -s 4M hikari_ssd_lvm /dev/mapper/hikari_ssd_luks
[root@hikari ~]# pvs -o +pe_start
  PV                          VG             Fmt  Attr PSize   PFree  1st PE 
  /dev/mapper/hikari_ssd_luks hikari_ssd_lvm lvm2 a-    74,42g 74,42g   8,00m

[root@hikari ~]# lvcreate -L 20G hikari_ssd_lvm -n root
[root@hikari ~]# lvcreate -L 20G hikari_ssd_lvm -n var
[root@hikari ~]# lvcreate -L 30G hikari_ssd_lvm -n home
[root@hikari ~]# lvcreate -l +100%FREE hikari_ssd_lvm -n swap
    

Jak je vidět, SSD využívám nejen k akceleraci systémových oddílů, ale také k akceleraci vybraných částí /home. V mém případě jde zejména o ~/.*. Přece jen v moderním systému se tam schovává nejedna databáze a mnoho konfiguračních souborů, se kterými KDE rádo často pracuje.

Škatulata hejbejte se poprvé

Mějme nakonfigurovaný fungující Arch Linux na disku, kde ho nechceme. Pro přesun systému na SSD využijeme dd následovně (z live flashky Archu):

dd if=/dev/mapper/lvm_storage-lvm_boot of=/dev/hikari_ssd_lvm/boot
dd if=/dev/mapper/hikari_hdd_luks_root of=/dev/hikari_ssd_lvm/root
dd if=/dev/mapper/hikari_hdd_luks_var of=/dev/hikari_ssd_lvm/var
    

První případ je kopírování nešifrovaných 100 MB dat, sranda. V druhém případě se kopíruje 20GB systém souborů z šifrovaného kontejneru na HDD do šifrovaného kontejneru na SSD. Pro A64 3000+ @ 2 GHz (1x) je to cca 5–6 hodin práce. Třetí případ se týká jen 10GB oddílu, takže to už je také celkem v klidu.

Zmiňoval jsem také snahu o univerzálnější pojmenování Povšimněte si druhého stupně přídavného jména, všichni víme že nejuniverzálnější je UUID. Hm, možná by se tohle přídavné jméno nemělo stupňovat… Vem to ďas. Použijeme tedy štítky souborových systémů (tune2fs přeštítkovává stávající souborové systémy, jinak umí třeba i zobrazit zajímavá čísílka…):

tune2fs -L hikari_ssd_boot /dev/hikari_ssd_lvm/boot
tune2fs -L hikari_ssd_root /dev/hikari_ssd_lvm/root
tune2fs -L hikari_ssd_var /dev/hikari_ssd_lvm/var
mkfs.ext4 -L hikari_ssd_home /dev/hikari_ssd_lvm/home
mkswap -L hikari_ssd_swap /dev/hikari_ssd_lvm/swap
    

No a protože jsme zkopírovali 10GB /var na 20GB oddíl, provedeme ještě jeho zvětšení:

[root@hikari /home/nik]# e2fsck -f /dev/hikari_ssd_lvm/var 
[root@hikari /home/nik]# resize2fs /dev/hikari_ssd_lvm/var 20G
    

Teď změníme konfiguraci systému (toho na SSD), aby správně montoval své oddíly:

# 
# /etc/fstab: static file system information
#
# file system                       dir  type options dump pass
devpts                            /dev/pts   devpts defaults 0 0
shm                               /dev/shm   tmpfs  nodev,nosuid 0 0

/dev/disk/by-label/hikari_ssd_root    /      ext4   defaults,noatime,nodiratime 0 1
/dev/disk/by-label/hikari_ssd_var     /var   ext4   defaults,noatime,nodiratime,nosuid,noexec 0 1
/dev/disk/by-label/hikari_ssd_boot    /boot  ext2   defaults,noatime,nodiratime 0 1
/dev/disk/by-label/hikari_ssd_home    /home  ext4   defaults,noatime,nodiratime 0 1
/dev/disk/by-label/hikari_ssd_swap    swap   swap   defaults 0 0
    

Jak je vidět z výpisu, tak právě tady se uplatnily dříve vytvářené štítky souborových systémů.

GRUB 2

Instalace GRUBU 2 se od dob první instalace Hikari poněkud změnila, ale do automatického generování konfiguráku se z lenosti pouštět nebudeme. Upravíme tedy stávající /boot/grub/grub.cfg (opět ten na SSD):

# Config gil for GRUB2 - The GNU GRand Unified Bootloader
# /boot/grub/grub.cfg

# Timeout for menu
set timeout=1

# Default boot entry
set deafult=0

# Arch Linux colors
set menu_color_normal=light-blue/black
set menu_color_highlight=light-cyan/blue

# Hopefully to get the right resolution
set gfxmode=1280x800
set gfxpayload=keep
insmod gfxterm
insmod vbe


# (0) Arch Linux
menuentry "Arch Linux" {
search --fs-uuid --no-floppy --set=root 0a65abc8-fd5f-4e5a-9177-f5fedf9137c7
linux /vmlinuz26 cryptdevice=/dev/disk/by-uuid/7b31337e-021d-421f-91df-0a81277825ed:hikari_ssd_luks \
    root=/dev/hikari_ssd_lvm/root ro resume=/dev/hikari_ssd_lvm/swap ro 
initrd /kernel26.img
}

# (1) Arch Linux with bootchart
menuentry "Arch Linux with Bootchart" {
search --fs-uuid --no-floppy --set=root 0a65abc8-fd5f-4e5a-9177-f5fedf9137c7
linux /vmlinuz26 cryptdevice=/dev/disk/by-uuid/7b31337e-021d-421f-91df-0a81277825ed:hikari_ssd_luks \
     root=/dev/hikari_ssd_lvm/root ro resume=/dev/hikari_ssd_lvm/swap ro init=/sbin/bootchartd
initrd /kernel26.img
}
    

Zde již používáme nejvíc nejuniverzálnější UUID (ls /dev/disk/by-uuid a zkopírovat správný řádek, pokud si nepamatujete ten správný řetězec). Šlo by se vyhnout UUID u /boot, ale stejně jsem nepřišel na to, jak přidat štítek LUKS oddílu, takže by to moc nepomohlo. Následuje „bind-chroot“ do systému na SSD a instalace GRUBU 2:

[root@hikari /]# grub_bios-install --boot-directory=/boot --no-floppy --recheck /dev/sdb
    

A když už jsme tam, otočíme ještě háčky v /etc/mkinitcpio.conf, nyní máme nejprve LUKS a až pak LVM, a vygenerujeme initramdisk. Nyní lze nabootovat do systému na SSD.

Velký diskový úklid

Aby bylo vše dotažené do konce, zbývá zpacifikovat oddíly na 500GB pevném disku. To obnáší přechod z LUKS nad LVM na LVM nad LUKS. Háček je v tom, že úložiště má 500 GB a ta data není zrovna moc kam dát. Nejprve ještě přesuneme tečkované adresáře z /home na HDD na nově vytvořený /home na SSD. Metodou pokus a omyl (tj. ls metaznaky | less jsem dospěl k následujícímu výrazu jako ideálnímu (nechceme si překopírovat ani nadřazený ani celý pracovní adresář):

cp -r .???* /mnt/
    

Nyní už hurá na další šoupání s oddíly…

Škatulata hejbejte se podruhé

Naštěstí se ruší 100GB oddíl pro Wine, přesunuté systémové oddíly a 100GB zálohovací oddíl se může také smazat. Tím se uvolňuje více než polovina diskové kapacity, takže by mělo stačit zmenšit LVM, zmenšit oddíl, na kterém je LVM, vytvořit druhý oddíl pro šifrovaný kontejner s LVM, zkopírovat tam systém souborů s daty, smazat oddíl s LVM, zvětšit oddíl se šifrovaným kontejnerem a zvětšit LVM na něm. Sranda ne?

Systém souborů s daty si zmenšíme, abychom nekopírovali zbytečně mnoho volného místa. Nyní zmenšení LVM:

pvresize --setphysicalvolumesize 220G /dev/sda1
    

Ha zrada! Logický oddíl s daty zabírá bloky na konci fyzického svazku LVM. Jdeme šíbovat:

pvmove -i 300 --alloc anywhere /dev/sda1:67096-119233 /dev/sda1:0-52136
    

Čísla bloků si zjistíme přes {pv,vg,lv}display, nezapomeneme kompenzovat rozdíly mezi pořadovými čísly bloků jdoucími od nuly a počtem bloků. -i 300 nám každých 5 minut napíše, jak to jde. Naštěstí kopírování bloků probíhá na LVM úrovni, tedy nad LUKSem. 200GB LVM oddíl se tak přesunul za cca 2 hodiny, na což by možná mohlo mít vliv i to, že se data kopírovala z plotny na plotnu, pokud tedy dobře rozumím tomu, jak to všechno funguje. Nyní konečně zmenšíme LVM příkazem výše.

Zbývá už jen zmenšit oddíl, na kterém se LVM nachází. Použijeme třeba cfdisk. Ne? Tak parted, gparted? Jak není podporováno?! To si to ze mě dělá ***! Tak tedy Google. Připravíme si mnoho kvalitních obětin božstvům, musíme totiž smazat oddíl v MBR a vytvořit nový začínající na stejném sektoru. Když to vyjde, máme menší oddíl, když ne, máme po datech. Jdeme na to:

fdisk -u /dev/sda
    

Důkladně si zapamatujeme číslo sektoru, kde současný oddíl začíná (67). Smažeme ho. Vytvoříme nový, řekneme fdisku, že má začít v sektoru 67… Cože, neplatné číslo sektoru?! Jo ono to automaticky zařezává… No to je pěkné. Bozi! Přečteme si manuál. O zařezávání oddílů ani slovo, nebo jsem už přepracovaný.

Konečné řešení diskové otázky

Kašlu na to… Prostě to smažu všechno a obnovím ze záloh. V zálohách však není úplně všechno. Vymyslíme, kam nacpat cca 35 GB nezálohovaných videí a dalších ptákovin. Smažeme staré balíčky z cache pacmanu na všech počítačích, ano, i na deset let starém Kanashimi! a nacpeme jejich disky k prasknutí. Než doběhnou všechna ta scp -r, jdeme dělat něco smysluplného.

Smažeme MBR, vytvoříme GPT, vytvoříme šifrovaný kontejner a LVM oddíly pro data a na zálohy. Všechno hezky pojmenujeme a oštítkujeme. Pustíme mnoho scp -r a pak i zálohovací skript využívající rsync, který obnoví zbývajících cca 100 GB dat ze záloh a opět jdeme dělat něco smysluplného.

Nyní už jen trochu hrabání se v konfigurácích: Rozšíříme /etc/fstab:

/dev/disk/by-label/hikari_hdd_data    /home/nik/Dokumenty  ext4   defaults,noatime,nodiratime 0 1
/dev/disk/by-label/hikari_hdd_bkp     /backup              ext4   defaults,noatime,nodiratime 0 1
    

a /etc/crypttab:

hikari_hdd_luks /dev/disk/by-uuid/c1261c96-37e4-4a70-a424-8542818ad140 /etc/keys/hdd.key
    

A je to!

Spousta nezajímavých číslíček

Z tabulky by mělo být vidět, k čemu je ten SSD disk dobrý:

Fáze	sezení-				sezení+
	HDD	SSD	SSD+	SSD++	HDD	SSD	SSD+	SSD++
LUKS	0:26	0:27	0:27	0:27	0:26	0:27	0:27	0:27
KDM	0:46	0:10	0:10	0:14	0:46	0:10	0:10	0:14
KLID	1:53	1:24	1:24	0:41	3:12	2:03	1:52	1:16
Suma	3:05	2:01	2:01	1:22	4:24	2:40	2:29	1:57

Měřil jsem stopkami v mobilu. LUKS znamená, za jak dlouho po stisknutí tlačítka power se zobrazí výzva pro zadání hesla k šifrovanému oddílu /. Proběhne tedy POST a pak se 1 s čeká v GRUBu. KDM znamená, za jak dlouho po stisknutí enteru (po napsání korektního hesla) se zobrazí přihlašovací obrazovka KDM. Proběhne tedy zejména odemykání všech při startu připojovaných LUKS oddílů a další ptákoviny jako start služeb a X11. KLID znamená, za jak dlouho po stisknutí enteru (po napsání korektního hesla) klesne vytížení CPU (zobrazuje plasmoid na ploše, viz snímek desktopu) pod 100 %. Proběhne tedy připojení LUKS oddílů uživatele – pokud jsou –, start KDE a obnovení sezení. Nejde tedy o pouhé proběhnutí úvodní „splash screen“. Jistou část tohoto času lze již s počítačem jistým způsobem pracovat.

Případ HDD je výchozí stav. V systému je pouze HDD na něm LVM na něm LUKS oddíly. Oddíly pro /root, /var, /tmp a swap se odemykají při startu systému, pro /backup, /wine a /home se odemykají až při přihlášení uživatele přes PAM_mount. Případ SSD je první krok v naší rošádě. V systému je HDD i SSD. Z HDD se používá pouze /backup, /wine a /home připojované přes PAM_mount. Na SSD je LUKS v něm LVM. Krom zrychlení SSD diskem se tedy odemykají pouze čtyři oddíly namísto sedmi. Případ SSD+ je druhý krok rošády. Využívá se /home na SSD, tam jsou tečkované adresáře, na HDD jsou stále tři oddíly připojované při přihlášení. Případ SSD++ je poslední krok rošády. Oba disky mají LVM nad LUKSem, dochází tedy pouze ke dvěma odemykáním šifrovaných kontejnerů a to při startu systému. Na HDD jsou pouze data a zálohy.

Varianta sezení- znamená start téměř prázdného sezení. Spouští se jen Yakuake, drobnosti v tray a Akonadi, které spustí KWallet. Nespouští se Nepomuk, protože tu na něj není dost RAM. Varianta sezení+ znamená start obvyklého sezení, tj. to co výše, a navíc Konatact a Rekonq s cca 7 oušky (Ábíčka, ArchWIKIny a nějaké blogy).

Výsledkem této téměř třívíkendové akce je tedy zrychlení startu v nejběžnějším případě z cca 4:30 na 2:00. Hell, yeah! Navíc by měl fungovat StD a mohl by být rychlý. A lze zapnout automatické přihlašování do KDE. Ale k tomu jsem se ještě nedostal.

       

Komentáře

[asdf]

po dlouhej době dobrej blog

[CEST]

Jojo, rychlost SSD je dobra. Nicmene s nasazenim na serveru mam velmi spatne zkusenosti. Meli jsme par serveru s SSD a disky odchazely jeden po druhym, prvni disk hned po zapnuti (jeste pred instalaci systemu) a posledni nekdy do mesice. Pritom klasicky disky nam chcipaji parkrat v roce (proste prirozene).

Na jednom serveru dokonce dva v mirroru chciply tak, ze jeden pri behu umrel (HW RAID ho vyradil jako vadny) a bezelo se z druheho, ktery pak ale taky nejak umrel a cela masina chcipla. Pri rebootu pak HW RAID zahlasil dost drsnou hlasku. Prvni chciply disk je nyni online, ale druhy je mrtvy, takze data na prvni nejsou synchronizovana.

Cili, SSD jako nejakou vyrovnavaci cache OK, ale na dulezity data spis ne, leda s nejakym hodinovym backup nebo v mirroru pet disku.

Az budou SSD stejne kvalitni jako klasicky plotnovy disky, tak jdu do toho.

[WEST]

+1

[Nicky726]

Jo jsem na výdrž zvědavej. HDD mi tu ale drží celkem dlouho, jeden chcípnul po 5 a druhý snad po 6 letech. O Intel SSD se jinak říkají dobré věci a záruka by měla být 3letá. No a zálohy samozřejmě jsou. Používám rdiff-backup /home a /etc na HDD (nyní denně, protože to bohužel celkem zabíjí práci na stroji, aby to běželo každou hodinu), a pak přes rsync to opravdu důležité na 4 stroje.

[CEST]

My jsme meli problemy s Corsair SSD na serverech, ale kolegove zkouseli take SSD Corsair a Intel na noteboocich a tusim snad na jeden nebo dva dost brzo vsechny chciply.

Rekl bych, ze kvalita SSD nezalezi na znacce, ale spis ta technologie sama o sobe ma problem. Ano, rychlost je super, ale to pak muzu pouzit pouze na SWAP a to jeste jenom na stanici, kde mi zase tolik vadit nebude, kdyz budu muset stanici jednou za cas restartovat. Uchovavat na tom data a system, abych jednou za mesic obnovoval ze zalohy, to radsi pojedu na klasickych SATA o trosku pomalejc.

Na serveru by se vyssi rychlost hodila, ale preferuju stabilitu pred ztratou dat (resp. pravidelnym obnovovanim dat ze zalohy).

[Jan]

Corsair na servery? No jo, to se pak vůbec nedivím. Na servery jsou enterprise SLC SSD, nějaký obyčejný MLC s 3 bity na buňku, který je určen na domácí použití toho asi tolik nevydrží.

Jednak jde o technologii a jednak o jiný firmware na jiný typ zátěže. Při běžném použití třeba v notebooku to klidně vydrží několik let, ale když od toho samého budeš chtít velký počet zápisů malých souborů, tak toho moc nevydrží.

Jinak nepozoruju, že měl někdo takový problémy, že by mu po pár měsících odešla většina SSD, to už musí být něco zvláštního.

[Heron]

Na jednom serveru dokonce dva v mirroru chciply tak, ze jeden pri behu umrel (HW RAID ho vyradil jako vadny) a bezelo se z druheho, ktery pak ale taky nejak umrel a cela masina chcipla.

Pokud to byl stejný typ disků, tak se nelze divit. Oba mají nějaký počet zápisů a v mirroru šly na oba disky stejné zápisy. Zde platí pravidlo dávat do mirroru různé disky ještě více, než u klasických.

[CEST]

No, to byl jediny pripad. Na dalsich serverech to chcipalo postupne - jeden den jeden disk, vymena, za nejakou dobu druhej disk. Meli jsme takhle asi 10-20 SSD v serverech. Jak postupne odchazely, tak jsme je nahrazovali SATA/SCSI diskama a od te doby, co jsou vsechny pryc, tak je zase klid.

[Heron]

Tak to jo. Ty zápisy jsou prostě smrt. Co doma vydrží roky, to na serveru chcípne do měsíce.

[Václav Kramář]

Není parametr nodiratime zbytečný? Viz http://lwn.net/Articles/245002/.

[Nicky726]

Aha, vida. No já to z manuálu pochopil, že zbytečný není. Tak si snížím počet znaků na řádku.

[cthulhu]

Alza (a asi i některé další shopy) dávají na 320tku 5 let záruku. imho bych zrovna teď s pořízením tohoto SSD vyčkal, viz. google "intel 320 8MB bug". btw. kdy už konečně bude LUKS vícevláknový? Pokud na čtyřjádru kopíruju z jednoho fyzického disku na druhý a oba mají šifrovaný oddíl, nedostanu se nad 35MB/s.. že bych zase po dlouhý době zkusil truecrypt?

[Cubic]

Koukam, ze jsi se ani nepokusil pouzivat discard jako mount volbu na ext4. Ja jsem to nastrkal do fstabu, chvili jsem to pouzival a pak se mi zacalo zdat ze je disk nejaky pomalejsi. Tak jsem trochu pidil potom proc a on device mapper jaksi brani v tom aby se efektivne pouzil TRIM na SSD. Takze jsem se zbavil celodiskoveho sifrovani a sifruju jen /home :(

V obavach o zivostnost disku jsem nacpal do pocitace 8GB RAM, zbavil se swpau a co slo jsem strcil do tmpfs.

[Nicky726]

Ano, zatím stále cryptsetup nepodporuje trim. Na podpoře se však pracuje, v gitu jsou už nějaké patche. Četl jsem ale také něco o bezpečnostních dopadech trimu na diskové šifrování (žel nebylo k tomu nikde nic bližšího). Zbavovat se kvůli tomu diskového šifrování nehodlám, u intel disků není dopad zas až tak razantní (nějaké testy jsou k dohledání na anandtechu). No a můžu to přeměřit za měsíc, za dva, zda se to promítne třeba do rychlosti startu.

Swapu se zbavovat nehodlám, minimálně chci používat StD. A protože jsem četl značně rozporuplné články ohledně životnosti, zdá se mi to celé poněkud přehnané. Víc ram snad bude, protože to, co mám nyní už prostě nestačí a /tmp pak jako tmpfs dám, aby to bylo rychlejší.

[Šangala]

Protože byla diskuze nyní odkazována odcuď, tak jsem si to přečetl až fčul.
Bezpečností dopady TRIMu na šifrované partition jsou hlavně ty, že lze z disku vyčíst jen použitá data, protože ostatní prostor je vynulovaný. Takže když si vyplníte před použitím šifrovanou partition náhodnými znaky, tak je to ok, ale jakmile tam čím dál víc zapisujete a hlavně mažete, tak se prostě nepoužívaná oblast plní ničím, tedy něčím konkrétním, ne náhodným .