SSD particionálása és az elhasználódás

Merevlemezek, vezérlők

Ha egy merevlemezt partíciókra bontunk, a merevlemez jól körülhatárolt, különböző részeire eltérő mennyiségben írunk. Tegyük fel, hogy az sda1 partíción egy Linux van, az sda2-n a neki megfelelő swap, az sda3-on pedig egy Windows. Ha a Linuxot sokat használom, különféle disztribúciókat tesztelgetek rajta, a Windows-t azonban csak néha indítom el akkor egyértelmű, hogy a merevlemez bizonyos részeire sokkal többet írok.

KÉRDÉS: Mi történik, ha merevlemez helyett SSD-n történik ugyanez? Vajon többet írok és törlök az SSD egy bizonyos részén (sad1, sda2), miközben a másik rész mintegy meg van kímélve (sda3), vagy ellenkezőleg, a partíciók felosztása egy felszíni réteg, amely mögött az SSD firmware-je szépen kiegyenlíti a terhelést, az elhasználódást?

[Hasonlóképpen: ha adott egy swap-fájl, amely egy alkalommal volt létrehozva, de folyamatosan változik a tartalma, SSD esetén egy bizonyos rész van túlterhelve, vagy ez is szépen eloszlik, szétszóródik az SSD szabad részének egészén?]

  • 19377 megtekintés

( mauzi v | 2013. 02. 18., h – 23:17 )

> SSD firmware-je szépen kiegyenlíti a terhelést

Jesz.

Tehát, ha jól értem, az SSD-firmware nemcsak egyazon partíción belül egyenlíti ki a terhelést, hanem akkor is, ha az egyik partíciót folyamatosan felülírom, a másikat pedig alig - tehát mintegy "globálisan" egyenlítgetve, merthogy a partíciók nem határolnak el egymástól rácspont-csoportokat?

( igor | 2013. 02. 18., h – 23:25 )

A hosszú élettartamhoz 60-70%-s telítettség ajánlott SSD esetén.

Ezen felül fontos a TRIM bekapcsolása, illetve noatime
fstab-ba: noatime,discard

A hosszú élettartamhoz ajánlott 60-70%-s telítettség hogyan értendő?:
1) Teljes mértékben elég, ha egyszerűen soha nincs megtöltve az SSD 60-70%-on túl, miközben particionáláskor az egész tárhelyet felhasználtam?
2) Vagy az segít igazából, ha 40-30%-át nem is particionálom az SSD-nek, meghagyva üres területnek? Nyújt ez valami pluszt ahhoz az esethez képest, ha az egész particionálva van ugyan, de nincs megtöltve?
3) Vagy az segít igazából, ha a "hdparm -Np" paranccsal bekapcsolom a HPA-t (Host Protected Area)? Nyújt ez valami többletet?

2.: ha magadnak csinálod, akkor partícionáld teljes méretre, hátha kell valamire a hely, de ezzel figyelembe vettem azt, h értelmes ember lévén tudatában vagy a technológia korlátainak, és tudod azt, h minél több helyet hagysz neki, annál jobb. Ha másnak csinálod, akkor én kissebbre partícionálnám, általában a teljes méret 80%-ra szoktam.

1. Ha van TRIM support vegig a fajlrendszertol az SSD-ig, akkor eleg. Egyebkent nem, mert az SSD nem fogja tudni, hogy ahol mar letorolt fajlok utan maradt "szemet" van a fajlrendszeren, az valojaban "ures" helykent kezelheto.

2. Ez a tuti modszer, de csak akkor igazan indokolt, ha valami miatt nincs TRIM. Pl ha dm-crypt vagy cryptoloop-pal encryptalt a diszk, akkor nem lesz trim. Egeszen uj kernelekben a dm-crypt mar elvileg tudja tovabbitani a trim-et a fajlrendszertol a block device fele, de alapbol nincs bekapcsolva es a security-s nepek szerint erosen ellenjavallt engedelyezni, mert szivarogtat informaciot. Leginkabb arrol szolgal egyertelmu informacioval, hogy mennyi tenyleges adatod van a fajlrendszeren, de nehany dolog (pl fs tipusa) is tippelheto a kulcs ismerete nelkul. Ennel komolyabb eredemenyes tamadasrol nem tudok, tehat alapvetoen a "letagadhatosagot" rontja.

3. A HPA (egyes korokben "overprovisioning" neven fut, bar szerintem kicsit hulye elnevezes), inkabb csak extra biztonsagot ad, hogy az SSD tenlyeg biztosan uresnek gondolja a teruletet. A 2. esetben ugyanis lehetnek sunyi problemak, ha egyszer valamikor mar irtal a particionalatlan teruletre, es nem lett letrimmelve. Ha 0-kkal van feltoltve a terulet, akkor nem fogod latni, hogy az SSD szerint is ures-e, vagy az SSD hasznalt, de 0-kkal feltoltott teruletkent ertelmezi.
---
Régóta vágyok én, az androidok mezonkincsére már!

Nem árt, ha már linux, ext4, brtfs, xfs, jfs használata. Továbbá a noop ütemező használata a cfq helyett. A swap, ha kell egyáltalán, mellőzése, vagy hdd-re rakni. Igazából egy általános használatú gép 2 GB memória felett már nem nagyon használ swap-et, kivéve a hibernációhoz. De ha mégis kell, akkor a swapiness erősen ajánlott.
# echo 1 > /proc/sys/vm/swappiness
menetközben illetve a megfelelő fájlba (/etc/sysctl.conf) beírással meg lehet őrizni az utókornak.
vm.swappiness=1
vm.vfs_cache_pressure=50
Amit még lehet:
/tmp könyvtárt tmpfs-sel használni, illetve ide cache-el a böngésző is.
Annak idjén egy ocz fórumon olvastam, hogy a partícionálást az
fdisk -H 32 -C 32 /dev/sda paranccsal kell csinálni ez a 4k-s eltolás miatt, de máshol meg
fdisk -H 224 -S 56 /dev/sda parancsot olvastam. Ezt nem nagyon értettem miért kell, de valaki biztosan tudja.

Hazérek leírom, csak ne válaszoljatok erre.

Egyébként a 32 head és 32 track 512KiB-ra alignál.
Az a lényeg hogy ki lehet számolni egy cilinder hosszát, az fdisk viszont cilinderhatáron kezdi a _partíciókat_. Fontos hogy a Start cilinder a 2. legyen.

Különben sokkal egyszerűbb a kezdőszektorokkal számolni.

Például ha az 2048. indexű LBA szektoron kezded az első partíciót akkor az 1MiB-ra van alignálva (egy szektor 512B)

A másik amit sok helyen elcsesszintenek hogy nem a page size méretére, hanem az erase block group méretére érdemes igazítani.

http://lwn.net/Articles/428584/

----------
[GB ≠ GiB] [MB ≠ MiB] [kB ≠ kiB] [1000 ≠ 1024] [Giga ≠ gram] [Mega ≠ milli] [Kelvin ≠ kilo] [Byte ≠ bit]

Közben emiatt nekem is felmerült egy kérdés: a /boot-om ext2, ergo nincs trim, a többi ext4. Az ext2-re tény, hogy ritkábban írok (Arch Linux amikor kernelt frissít), de azért megkérdezném: mi a legrosszabb ami történhet, ha az az 512 MB egy trim-képtelen partíción van? Akkor is átpakolgatja időnként a firmware máshova?

Egyik partíció sincs amúgy 75%-nál jobban tele (/boot 28%-ig van tele kb.), nem tudom ez számít-e.

Két éve, hogy megy a gépemben minden nap egy ADATA S599. Nem particionáltam semmit, nem igazítottam partíciót (csak átklónoztam a régi rendszert HDD-ről), ReiserFS van rajta (tudtommal nem tud TRIM-en), nem nagyon figyelgetem, hogy mennyi adat van éppen rajta, fogalmam sincs, hogy mit csinál, de nem is érdekel.

Még működik. Majd szólok ha elromlott.

--
trey @ gépház

( mikebela777 | 2013. 02. 19., k – 20:10 )

Köszönöm a válaszaitokat. Lehet, hogy buták a kérdéseim, de az történt, hogy váratlanul szakadt a nyakamba egy SSD, az első SSD-m. Aznap reggel még nem tudtam, hogy egy szerencsés garanciás csereberét követően SSD-m lesz este, és nem "készültem fel" a használatára. Szóval lenne még egy másik kérdésem is:

Hosszabb használat után (például néhány újraklónozásos kényszerhelyzetet követően) javít-e az SSD teljesítményén a totális visszaállítás a gyári üresség állapotába az "ATA Secure Erase" metódussal (time hdparm --user-master u --security-erase password /dev/X)? Arra gondolok, ami ITT van leírva.

( EdgarPE | 2013. 02. 20., sze – 19:50 )

Az itt leírtak hasznos infók, de: ne parázd túl a dolgot.

Én egy 80G-s Intel SSD-t nyúztam 2-2.5 évig úgy, hogy semmi extra védelmet nem kapott. A /tmp nem volt áthelyezve, TRIM-et nem támogatta a notebook, és a home encrypted-volt (sok adatforgalom). És gyakran csontra teleírtam az SSD-t torrentezés közben. Ha jól emlékszem napi átlag 20-30 GB adatot írtam a 80GB-os SSD-re.

Mikor nagyobbra cserlétem 7 "elhasznált sector" volt rajta, de ezeket kiváltotta házon belül fentartott jó sectorokkal, így a Smart-ban az elhasználódás paramétere 100-ról 99-re ment le. 0-nál vagy 10-nél (nem emlékszem) van gond. 2 év alatt 1% ...

Szóval no para, használd bátran, particionáld ahogy akarod. Én azt javaslom particionáld fel az egészet maximálisan ahogy használni akarod, "tune2fs -m"-mel állíts a partícióra reserved block-ot 10%-ra aztán jónapot. Ha meg kell a hely 1-2 napig nyugodan leveheted 0%-ra is.

+1; tényleg jó a téma. "Örököltem" egy ITX lappal egy valamilyen netbook-ból kiszedett pSSD-t, nem tudom milyen volt konkrétan az előélete, de a lapos és egy házigép után most engem szolgál már lassan másfél éve. TRIM és társai beállítva, meg az írásigényes dolgok a RAM-ba vannak kipakolva aztán eldöngicsél rajta a Debian...

Milyen nand flash van, volt azon az ssd-n? Mert csak elrettentésül a különböző flash-ek összehasonlítása:
slc(legelső és legrégebbi) : 1 bit cellánként, 100000 írás/törlési ciklus és a leggyorsabb
mlc : 2 bit, 3000 !!!! igen 3000 írás/törlés és közepes sebesség
tlc (ez a legújabb és legolcsóbb): 3 bit, 1000 !!!, és a leglassabb
Azért ebből érzékelhető, hogy az mlc és tlc esetén, már nem árt némi tuning ás állagmegóvás.

Nem tudok eligazodni a számokon. Nékem egy Kingston HyperX 3K 120GB SSD-m van. Namármost ha a 3K 3000 felülírást jelent, akkor az 3000 x 120GB = 351TB. De ha csak 1000-t is veszünk, az 117TB. Errefel a honlapjukon odaírják jól elrejtve, apró betűkkel, hogy Total Bytes Written (TBW): 120G: 96TB. Fogalmam nincs ezek után, hogy mit jelöl a 3K a megnevezésben.

Osztom, de egy ellenpélda, Asus mSATA 8GB SSD - futott 1 év 7 hónap - általános desktop használat.
Szerencsére garancia időn belül állt fejre.
Hiba jelenség:
Teljesen belokkolt, de ugyanakkor olvasható maradt. Nem lehetett semmit írni rá, újraparticionálni, gyalulni stb.
Fórumok szerint, ilyenkor a memória rész előtti vezérlő kerül valahol tri-state állapotba, maga a tárolás egészséges maradt.
Nos ezt nem tudhatom, de logikusnak tűnik.

( mikebela777 | 2013. 02. 21., cs – 09:02 )

Nem kell a HPA-val bajlódni (hdparm -Np). Kipróbáltam (egy Parted Magic livecd-ről). A linuxok mindenféle hibaüzenettel reagáltak, mert nem ismerték fel, hogy HPA-s az SSD. De a Windows is a teljes rendelkezésre álló kapacitást jelezte. Muszáj volt, kikapcsolnom, hogy ne okozzon hibákat.

( uid_16313 | 2013. 07. 11., cs – 10:45 )

Nem akartam új szálat nyitni, ezért írok ide.
Nemrég vásároltam bátran egy TLC-s Samsung SSD 840 120GB-ot.

Összeolvastam már mindent a témában, de még mindig nem teljesen világos egy-két ponton, hogy hogyan érdemes használni.

Ùjrapartícionáltam az eszközt, secure erase nélkül, és hagytam kb. 10% partícionálatlan területet. Van egy 200 MB-os efi fat32-es partíció, illetve egy 100 GB-os EXT4 a /-nek. Más nincs. Swap nincs, temp-ek memóriába irányítva, stb...

Lefuttattam egyszer a trim-et telepítés után, azóta sem.

Kérdésem az, hogy felismeri-e az SSD Ubuntu alatt a 10%-os partícionálatlan területet (over provision), vagy kell ahhoz is valami trükközés? Ismétlem, secure erase nem volt elötte.

Ubuntu 13.04-nél az FSTAB-ba be van írva a "noatime,discard". Nem tudom, hogy discard kell-e vagy nem? Itt is ellentmondásos információim vannak.

Ha a /var/log mappát tmpfs-be irányítom, kell-e valami plusz trükk, gondolok itt arra, hogy restart után mindig üres lesz, azon felül, hogy nem lesznek log-jaim visszamenöleg?

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

"Kérdésem az, hogy felismeri-e az SSD Ubuntu alatt a 10%-os partícionálatlan területet"

Nem kell felismerje, a lényeg hogy legyen üres rész az SSD-n. Lehet particionált is, csak ne legyen rajta konkrétan adat. Ha egyszer-kétszer betelik a partició rövid időre az sem gáz.

"Nem tudom, hogy discard kell-e vagy nem? Itt is ellentmondásos információim vannak."

Érdemes, de nem életbevágó. Ez a TRIM funkció. Pl. így tudod nézni hogy megy-e a TRIM:

https://sites.google.com/site/lightrush/random-1/checkiftrimonext4isena…