Dotaz: Co dát na SSD a co na HDD,

[Houmr]

Chci si do nového PC dát SSD kvůli jeho rychlosti. Zároveň tam chci mít i klasický plotnový disk na data, co se na SSD nevejdou (SSD plánuji 128 GB). Bude vhodnější jak systém tak /home dát na SSD, a druhý disk přimountovat někam bokem, nebo na SSD nechat jen systém, a /home dát přímo na ten klasický disk? Zajímá mě jak hledisko rychlosti tak životnosti toho SSD.

---

---

Odpovědi

[Sten]

/home na SSD znamená kratší životnost SSD a vyšší rychlost vašeho DE, protože všechny konfigurační soubory, cache a databáze budou na SSD. IMO o dost větší vliv na životnost ale má volba a nastavení souborového systému. Můžete také zkusit dm_cache nebo BCache, které umí automaticky na SSD kopírovat data, která se nejčastěji potřebují, a zároveň jsou díky přírůstkovému zápisu mnohem šetrnější na SSD, ale výkon je nižší, než pokud je systém čistě jen na SSD, a může být problém to správně rozjet (u BCache jsem měl problém, že je sice ve všech moderních systémech v jádře, ale initramdisk se s ní nemá moc rád).

[nobody]

- / a /home na SSD
- nastavit v /etc/fstab noatime(nebude zapisovat ke kazdemu souboru cas posledniho cteni) a discard(trim)
- misto discard (pokud bude podporovat tve SSD) je lepsi fstrim v cron (balik util-linux)
- pro /tmp nastavit (pokud to tve distro nedela rovnou) pouziti tmpfs (= v ram)
- swap vypnout, pokud nechces uspavat na disk(ssd) nebo nastavit vyuziti az v krajnim pripade pomoci Swappiness na 1

to je myslim idealni z hlediska max rychlosti a rozumne zivotnosti...
a jinak neni od veci, delat zalohu rsync ssd > hdd :)

[kuba77]

Já teda ještě mám v /etc/fstab nastavenou složku .cache a .thumbnails z mého home jako tmpfs.

A ještě by se dala složka s cache, do které balíčkovací systém stahuje při aktualizacích balíčky, hodit na HDD. V případě Archu to je /var/cache/pacman.

[Delaunay]

Víceméně souhlasím s tím, co zde uvedl nobody. Jen doplním:

1. nastavit deadline nebo noop I/O scheduler
2. zvýšit interval dirty_writeback
3. na HDD přesunout zřídkakdy využívaná nebo objemná data

Ze životnosti SSD disku bych obavy neměl. Používám je mnoho let a na rozdíl od mnoha předešlých HDD disků mi ještě žádný neumřel.

[mca]

Kazde SSD ma dnes Wear Leveling, ktery se stara o rovnomerne opotrebeni NAND a vesele rozhazuje (cti fragmentuje) interni topologii. Na ten curbes nastupuji algoritmy jako Garbage Collector a UNMAP (TRIM), kteri se staraji o uklid, mapovani a okamzite pouziti. Davno je pryc doba, kdy mela MLC NAND 3000P/E, ale vycerpat NAND, to bys musel narazit na poradne smejdske TLC a jeste mit extra zapisy. Za 3 - 4 roky s tim svihnes a koupis jiny, rychlejsi (to uz bude snad NVMe standardem) a s vyssi kapacitou.

SSD ochazi proto, ze chcipne nejcasteji radic, nebo se rozpadnou protoze chlapci od bobri reky, ekoteroriste, vymysleji hovadiny jako ROHS a zivotnost spoju nepresahuje 4 - 5 let. Radice odchazi z pravidla proste proto, ze nemaji vyresene tepelne odvody. To je takova mala tepelna ploska, ktera spojuje radic s obalem a prenasi teplo na povrch, kde staci minimalni airflow (SSD s kondenzatory maji 55°C), jako u M2/mSATA, kde to proste staci naprimo. Ty lepsi radice maji jeste ochranu v podobe thermal throttlingu, tzn. se podtaktuji.

Strucne ... cokoliv a vsechno, co se na ten SSD vejde, protoze filmum staci kapacitni 5400rpm plotna.

[lertimir]

Souhlas. Z opotřebením není třeba si dělat starosti. Při zápisových odhadech cca na 3000 zápisů do buňky je to zápis asi 370TB do disku, to dělá při 10GB zápisu za hodinu a 3000 hodinách ročně asi 10let. Pokud přes SSD nestěhuji multimédia tak je to neutahatelné a padne na jiný problém. Pro ilustraci můj SSD mi hlásí množství zápsaných dat ve SMART a po 3 letech používání hlásí.

Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   109   109   050    Pre-fail  Always       -       0/23502573
  5 Retired_Block_Count     0x0033   100   100   003    Pre-fail  Always       -       1
  9 Power_On_Hours_and_Msec 0x0032   080   080   000    Old_age   Always       -       17615h+15m+00.830s
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       197
171 Program_Fail_Count      0x0032   000   000   000    Old_age   Always       -       1
172 Erase_Fail_Count        0x0032   000   000   000    Old_age   Always       -       0
174 Unexpect_Power_Loss_Ct  0x0030   000   000   000    Old_age   Offline      -       70
177 Wear_Range_Delta        0x0000   000   000   000    Old_age   Offline      -       7
181 Program_Fail_Count      0x0032   000   000   000    Old_age   Always       -       1
182 Erase_Fail_Count        0x0032   000   000   000    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0022   128   129   000    Old_age   Always       -       128 (0 127 0 129 0)
195 ECC_Uncorr_Error_Count  0x001c   120   120   000    Old_age   Offline      -       0/23502573
196 Reallocated_Event_Count 0x0033   100   100   003    Pre-fail  Always       -       1
201 Unc_Soft_Read_Err_Rate  0x001c   120   120   000    Old_age   Offline      -       0/23502573
204 Soft_ECC_Correct_Rate   0x001c   120   120   000    Old_age   Offline      -       0/23502573
230 Life_Curve_Status       0x0013   100   100   000    Pre-fail  Always       -       100
231 SSD_Life_Left           0x0013   100   100   010    Pre-fail  Always       -       0
233 SandForce_Internal      0x0000   000   000   000    Old_age   Offline      -       14073
234 SandForce_Internal      0x0032   000   000   000    Old_age   Always       -       18386
241 Lifetime_Writes_GiB     0x0032   000   000   000    Old_age   Always       -       18386
242 Lifetime_Reads_GiB      0x0032   000   000   000    Old_age   Always       -       13068

takže za 17000 hodin zapsal 18TB dat, realokoval 1 buňku a live cyklus je pořád na 100%. A i když na disku normálně pracuji a vše co dělám jde primárně na něj, a aktualizace jedou v hodinové kontrole a několik jich za den projde, jede na disku akonadi s nepomukem a indexuje více než jen přimo tento prostor, přesto vše je zápis někde u 1GB za hodinu s takovou mi opotřebení vydrží na skoro 100 let provozu což asi nevyužiji. Jediné, co je mi divné je teplota, ale to může být jen chybně zkalibrováno, disk je ve velkém desktopu a je na dotek chladný.

[vasek]

Doslechl jsem se od technika podpory DELL, že SSD v noteboocích mění častěji než běžné rotační disky. Prý najednou přestanou fungovat a je problém z toho cokoliv dostat - asi odejde ten již zmiňovaný řadič. Docela by mě zajímalo, jak jsou na tom serverové enterprise-class SSD co se týče kvality zpracování ...

Jinak nárůst rychlosti po výměně za SSD nemusí být nějak rapidní - záleží na použití. Linux toho dost drží v RAM. Já mám na SSD všechno a při normálním používání (filmy, kancelářská otročina, web, programování) je výkon o něco vyšší než HDD, ale ne nějak brutálně vyšší. Proto bych dal na SSD všechno, aby to mělo nějaký smysl.

[mca]

Jsou mnohem vice predikovatelne, ale stejne se pouzivaji mirrorovane systemy, takze v tom neni poblem. Enterprise ale nejsou jen serverove disky (tenhle omyl tu proste bezi roky), ale i obycejne desktopove SSD, ktere maji funkce jako statistiku a umeji monitorovat kazdou NAND, podporuji vzdalenou spravu. Rozdil je v tom, ze Crucial M550 takove vlastnosti (firmware dela disk) nema, kdezto Micron M550 ano. Ani jeden neni serverovy SSD, presto jsou to enterprise SSD. Enterprise znamena prostredi, integraci, spravu a vlastnosti.

Serverove SSD maji napr.: 2 kanaly navic (RAIN/RAISE a dalsi nazvy) v tech lepsich SSD, Garbage a dalsi funkce musi bezet bez ohledu na workload disku (tedy nikoliv jen v IDLE) a struktury se tak optimalizuji v realnem case, maji kondenzatory nebo baterie (write-back), maji mnohem vyssi over-provisioning (25%+), minimalne 3DWPD ... atd. Tech rozdilu je tolik, ze by to vydalo na samostatny roman.