Dotaz: Jak ověřit, že TRIM funguje na RAID 0 poli nad SSD disky

[tobik]

Nainstaloval jsem si Linux na RAID 0 pole nad dvěma SSD disky. Běží to velice hezky. Podle doporučení jsem se rozhodl aktivovat trim pomocí parametru discard ve fstab. Zdá se, že to funguje, v dmesg jsem žádnou chybovou hlášku nenašel a dle hdparm -I /dev/sda je funkce TRIM podporována. Přesto bych rád ověřil, že TRIM skutečně funguje, vzhledem k té poněkud divoké konfiguraci.

Našel jsem na internetu postup, při kterém se vytvoří soubor, zjistí počáteční sektor, smaže a pak se pomocí hdparm --read-sector ověří, že sektory jsou skutečně po čase nahrazené nulami. Problém je, že já nevím, jak přistoupit přímo k sektorům na diskovém poli.

~ # hdparm --read-sector 234346496 /dev/md125

/dev/md125:
/dev/md125 is a RAID device: please specify an absolute LBA of a raw member device instead (raid1 only)
Aborting.

Evidentně toto funguje jen pro RAID 1. Mohu přistupovat přímo k /dev/sda (resp. /dev/sdb), ale k tomu bych potřeboval napřed zjistit, kde skutečně je ten soubor fyzicky uložený (vzhledem k principu RAID 0 bude půlka na jednom disku, půlka na druhém). Nějaké nápady?

Odpovědi

[NoXO]

Ahoj, možná mimo mísu, ale není RAID0 s SSD přehnané, když propustnost SATAIII je 6Gbit :) Jediné s čím vždy zápasím je IO :) Kolik ti to čte a zapisuje ?

[tobik]

To je celkem rozumná připomínka :) Nicméně je to notes, a přišel už s RAID 0 přednastaveným. Na tom Windows 8, které jsem chtěl zachovat, takže jsem se rozhodl to prostě nainstalovat k tomu s tím, že se uvidí, jak to běhá. A běhá to dobře :) Další výhodou je, že s jedním 500GB diskem se prostě pracuje lépe (pohodlněji se dá rozdělit), než se dvěma 256GB.

Pak je tu ještě jeden důvod. Jedná se pouze o hypotézu, ale dává docela smysl. RAID 0 rozkládá zápis rovnoměrně na dva disky. U běžných disků to znamená především zvýšení výkonu, ale u SSD to podle mě může i zaručit lepší rozložení opotřebení. Jak je známo, SSD mají omezený počet zápisů. Kdybych měl Linux pouze na jednom disku, tak ten by se opotřeboval mnohem rychleji, než ten druhý s Windows. Takže IMHO RAID 0 je docela dobrý nápad na SSD.

Ohledně rychlosti zápisu, toto jsem naměřil těsně po instalaci (cca 1/3 pole zaplněná):

# dd if=/dev/zero of=output bs=8k count=2024k
16 978 542 592 bytes (17 GB) copied, 18,4724 s, 919 MB/s

V tuto chvíli dám (po týdnu používání při 2/3 zaplnění disku) mezi 500-750 MB/s... podle nálady :) I proto bych chtěl ověřit, že ten trim korektně funguje.

[Atom321]

Kdybych měl Linux pouze na jednom disku, tak ten by se opotřeboval mnohem rychleji, než ten druhý s Windows. Takže IMHO RAID 0 je docela dobrý nápad na SSD.

Ta hypotéza o rozkládání platí, jen pokud stripe-blok RAID0 je stejně velký jako sektor SSD a zapisují se souvislé velké bloky. Příklad:

• SSD se 128K sektorem bez RAIDu
  Zápis 128KB bloku -> přepis jednoho 128K bloku na jednom SSD.
  Zápis 256KB bloku -> přepis dvou 128K bloků na jednom SSD.
  Zápis 512KB bloku -> přepis čtyř 128K bloků na jednom SSD.
  
  
• RAID stripe 128KB (ideální varianta)
  Zápis 128KB bloku -> přepis jednoho 128K stripe -> na jeden disk 128K -> přepis jednoho 128K bloku na jednom SSD (tedy totéž).
  Zápis 256KB bloku -> přepis dvou 128K stripe -> na oba disky 128K -> přepis jednoho 128K na každém SSD (zlepšení).
  Zápis 512KB bloku -> přepis čtyř 128K stripe -> na oba disky 256K -> přepis dvou 128K na každém SSD (zlepšení).
  
  
• RAID stripe 64KB
  Zápis 128KB bloku -> přepis dvou 64K stripe -> na každý disk 64K -> přepis jednoho 128K na každém SSD (zhoršení).
  Zápis 256KB bloku -> přepis čtyř 64K stripe -> na každý disk dva 64K bloky -> přepis jednoho 128K na každém SSD (zlepšení).
  Zápis 512KB bloku -> přepis osmi 128K stripe -> na každý disk čtyři 64K bloky -> přepis dvou 128K na každém SSD (zlepšení).
  
  
• RAID stripe 256KB
  Zápis 128KB bloku -> přepis jednoho 256K stripe -> na jeden disk 256KB -> přepis dvou 128K na jednom SSD (zhoršení).
  Zápis 256KB bloku -> přepis jednoho 256K stripe -> na jeden disk 256KB -> přepis dvou 128K na jednom SSD (totéž).
  Zápis 512KB bloku -> přepis dvou 256K stripe -> na každý disk čtyři 64K bloky -> přepis dvou 128K na každém SSD (zlepšení).
  
  

Tedy, podle mojí hypotézy, by se samostatný disk opotřeboval (například) za 3 roky, ten druhý méně používaný za 6. V RAID0 odejdou za 4,5 roku oba disky naráz.

[tobik]

Hezky vysvětlené :) Toto je konfigurace mého disku (něco je vynecháno):

parted -l
Error: Invalid argument during seek for read on /dev/sda                  
Retry/Ignore/Cancel? C                                                    
Model: ATA SanDisk SD5SF225 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown

Error: /dev/sdb: unrecognised disk label                                  
Model: ATA SanDisk SD5SF225 (scsi)
Disk /dev/sdb: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown

Model: Linux Software RAID Array (md)
Disk /dev/md125: 503GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Pokud to dobře čtu, tak jak RAID, tak přímo fyzické disky mají velikost sektoru 512B. Tedy by to mělo být v pořádku. RAID je nakonfigurovaný přímo od výrobce, tak bych ani nic jiného nečekal. Na tu druhou stranu, nerozumím tomu, proč je zde uvedeno 512B, zatímco všude jinde se u SSD disků uvádí hodnota o řád vyšší, tedy 512KB. A YaST (používám openSuse) u RAIDu ještě uvádí údaj "Velikost kusu: 128 kB", což netuším, co je.

Ale jinak by mě stejně zajímalo, jako je to s tím TRIMem. Teoreticky by neměl být v ničem problém... ext4 vydá příkaz k TRIMu, RAID vrstva ho zachytí a dopraví až k disku...

[Atom321]

Těch 512B odpovídá velikosti sektoru klasických disků. Je to kvůli zpětné kompatibilitě se staršími BIOSy a operačními systémy. S fyzickou organizací NAND flashe to nemá nic společného.

"Kus" 128kB je zřejmě "stripe" RAIDu, kterou jsem popisoval výše.

NAND Flashe jsou organizované v sektorech (typicky 128,256,512KB) a stránkách (typicky 2-4KB). Čte a zapisuje se vždy celá stránka. Zápisem se překlápí binární 1 na 0, ale ne naopak. Pro změnu 0 na 1 je potřeba vymazat celý fyzický sektor (256/512KB) a poté znovu zapsat. Mazání sektoru je řádově pomalejší než čtení/zápis.

O převod mezi 512B logickými sektory a fyzickou pamětí se stará řadič v SSD. Ten právě řeší specifika zápisu/mazání NAND flashe, rozkládání zátěže, samoopravné/kontrolní součty, příp. kompresi a další věci. Příkaz "TRIM" řadiči říká, že označený logický prostor disku je volný a může tak vymazat fyzické sektory, kde jsou data uložena. Vytvoří si tím zásobu vymazaných sektorů, do kterých může později rychle zapsat bez pomalého mazání. Novější řadiče navíc data komprimují - zapisují/čtou méně dat (stránek), případně obsadí méně sektorů a udrží si tak větší zásobu volných - vymazaných.

Celý tenhle šelmostroj v řadiči SSD je výrobcem odladěný na provoz s 512B logickými sektory ve Windows s NTFS. Může se zásadně lišit mezi různými typy disků, ale i různými sériemi nebo jen updaty firmwaru téhož SSD. Se zapojením v RAIDu se tak nějak nepočítá a je ve hvězdách, co to vlastně dělá.

[tobik]

Tak v podstatě první přímo relevantní odpověď k původnímu dotazu - "Se zapojením v RAIDu se tak nějak nepočítá a je ve hvězdách, co to vlastně dělá" - to zní povzbudivě :D Já spoléhám, že když to takto nakonfiguroval už výrobce a já tu konfiguraci použil, tak by to snad mělo být nastavené dobře. Výkon, alespoň co mohu soudit, tomu odpovídá (viz výše). Pokud to dobře chápu, tak jediná potíž tedy může být v tom TRIMu, že se správně nepropaguje přes tu RAID vrstvu (čehož se koneckonců týkal tento dotaz). Nicméně pokud výkon začne časem klesat, tak bych mohl RAID rozpojit, na disky si zapsat nuly sám a dál to používat klasicky odděleně, kde by už TRIM měl fungovat bez problémů.

Druhá věc je to opotřebení... čistě teoreticky pokud bych měl ty velikosti bloků skutečně nešťastně nastavené (jak sám píšete), tak by se disky opotřebovaly rychleji, než kdyby byly rozdělené. Nicméně i v tomto bodě mi přijde rozumně důvěřovat výrobci, protože on tam ty disky strčil a nakonfiguroval.

[Atom321]

Tak prostě důvěřujte výrobci i v nastavení TRIMu a máte to

[tobik]

Asi nic jiného nezbude, když je na toto téma tak málo dostupných informací :) Ale spíš jde o to, že zatímco RAID konfiguroval výrobce, tak Linux už mám na triku já. A je otázka, zda toto nevyžaduje nějaké speciální zacházení.

[Michal2]

Hodne ovsem take zalezi na mire zaplneni disku (a tedy na kapacite, se kterou muze pracovat algoritmus wear levelingu). RAID0 rozlozi zaplneni rovnomerne.

[tobik]

Všude doporučují nechat si aspoň 10% disku volných, právě kvůli tomu rozložení. Já jsem se tím řídil a nechal si 50GB úplně nealokovaných. Takže by to mělo být v pořádku. A právě vzhledem k tomu dualbootu mi RAID přijde jako dobrý nápad, protože jinak by byl disk s Linuxem podstatně více opotřebený, zatímco ten Windowsový by byl téměř netknutý :)

[lertimir]

RAIDu 0 jako hlavní disk bych se bál jako čert kříže. A pokud bych to používal tak s nějakým totálním zálohovacím režimem.

[tobik]

Tak je pravda, že riziko selhání je dvojnásobné. Na tu druhou stranu, moje zkušenosti jsou takové, že kdykoliv někde někdo přišel o data kvůli poškozenému disku, tak to bylo proto, že ten notebook spadl zapnutý ze stolu. Na což jsou klasické disky docela citlivé :) ale SSD diskům to naopak moc nevadí.

Kdyby ten notebook přišel úplně prázdný a nijak nenakonfigurovaný, tak bych asi RAID 0 nezvolil. Buď bych to nechal rozdělené a nebo šel spíše cestou RAID 1 (bezpečnost a i rychlost čtení). Realita je taková, že notebook přišel s RAID 0 a koneckonců to má svoje výhody - s jedním 500 GB diskem se pracuje lépe než s 2x250, výkon je vyšší a to opotřebení se rozkládá.