SSD konfigurálása linux-hoz

Merevlemezek, vezérlők

Sziasztok!

A laptopomban kicseréltem a hdd-t egy Intel SSD-re. Olvastam egy érdekes cikket a prohardveren az SSD-kről úgy általában(http://prohardver.hu/teszt/mindent_az_ssd-krol/bevezetes_ssd-alapok.html), és ebben is kitérnek a partíciók 512Kbyte-os határra igazítására. Arra lennék kíváncsi, hogy ezt hogyan tudom megtenni, illetve, hogy egy teljesen szűz SSD-nél szükség van-e rá, vagy esetleg az OS ( Frugalware 1.3 ) telepítésnél automatikusan így csinálja-e. Intel X25-V 40GB-ról van szó, terveim szerint egy 3 Gigás swap partíció lesz rajta a fő rendszer partíció mellett, bár azon is gondolkodom, hogy 2GB ram mellé nem is nagyon kell nekem a swap.

Köszönöm előre is a válaszokat.

U-dash

  • 15704 megtekintés

( mulder | 2010. 08. 24., k – 14:30 )

swap particiot nem nagyon rakned SSDre. Ha sokat hasznalja a gep, akkor eleg gyorsan kinyirja az ottani modulokat ...

( WN31RD | 2010. 08. 24., k – 14:50 )

Fogalmam sincs, hogy a Frugalware mit kezd magától az SSD-vel, én manuálisan csinálnám, akkor biztosan jó lesz. Ha új telepítést akarsz a file-ok régi vinyóról történő másolása helyett, akkor egy live CD-ről hozd létre a partíciókat az alábbi módon, és a Frugalware telepítőjében biztos megadható valahogyan, hogy a már létező partíciókat használja.

Ha 32 fejet és 32 szektort adsz meg az fdisk-nek, akkor automatikusan 512 KB határra fogja igazítani a partíciókat (32*32*512 = 524288), szerintem ez a legegyszerűbb és legnehezebben elrontható módszer:

thinkpad:~# fdisk -H 32 -S 32 /dev/sda
Command (m for help): p
Disk /dev/sda: 160.0 GB, 160041885696 bytes
32 heads, 32 sectors/track, 305255 cylinders
Units = cylinders of 1024 * 512 = 524288 bytes

Ezután létrehozod a partíciókat, ahogyan szeretnéd, másra nem kell figyelni. Ha esetleg titkosított partíciókat használsz (hordozható gépen nem árt), akkor az "--align-payload=1024" paramétert kell megadni a cryptsetup-nak, hogy 512 KB határra igazítsa az adatterületet. Ha LVM-et használsz, akkor a "--dataalignment 512K" opcióra lesz szükség a pvcreate parancsnál.

Swapre szükséged lesz, ha hibernálni akarod a rendszert. Én hordozható gépen mindenképpen létrehoznám, mert utólag nehezebb lesz. Nem kell aggódni amiatt, hogy tönkremegy ettől az SSD, én kb. egy éve használom így (160 GB Intel G2 MLC), a logolás mennyiségét sem csökkentettem, ráadásul backup is megy az SSD-re kb. kétóránként, és a SMART szerint semmi baja. Mire elkezdene tönkremenni, úgyis valami újabb eszközre vált az ember.

Azt tapasztalom, hogy az --align-payload=1024 nincs hatással a cryptsetupra, mert a luksDump szerint ugyanúgy 2048 marad az értéke, ami a default érték.
Ellenben a szintén több helyen olvasható --align-payload=8192 már érvényre jut a luksDump szerint: Payload offset: 8192

Ugyanakkor érdekes, ha nem adok neki paramétert, a kernel segítségével automatikusan Payload offset: 1032 -t állít be.

/"Align payload at a boundary of value 512-byte sectors. This option is relevant for luksFormat. If not specified, cryptsetup tries to use topology info provided by kernel for underlying device to get optimal alignment. If not available (or calculated value is multiple of default) data is by default aligned to 1 MiB boundary (2048 512-byte sectors)." - cryptsetup(8)/

( bounty v | 2010. 08. 24., k – 16:00 )

Arra figyelj, hogy discard opcióval mountold az ext4 partíciót, a TRIM-hez. A noatime se árt.

Én ezeket állítottam még be, sok ssd fórumtopik olvasgatás után.

echo deadline > /sys/block/[ssd]/queue/scheduler
echo 1 > /sys/block/[ssd]/queue/iosched/fifo_batch
vm.dirty_ratio = 40
vm.dirty_background_ratio = 1
vm.dirty_writeback_centisecs = 2000

( kulik | 2010. 12. 27., h – 10:07 )

hahó! pont ezzel a vinyóval szemezek én is :D

gondolom azóta beraktad neki....
észrevehető a sebesség különbség, illetve tapasztalsz valamit fogyasztás terén? mármint látványosan tovább bírja aksival így?

a másik, filerendszerekről nem nagyon esett még szó itt... ugye az ssd alapvetően máshogy működik, mint a hdd.

Szia, bocs a késői válaszért.

Igen, NAGYON észrevehető a sebesség különbség. Egyszerűen nem kell várni a programokra, minden azonnal, egy szempillantás alatt indul. Fogyasztást nem mértem, a notim amúgy is eléggé melegszik, ezért ebben sem látok különbséget. Az akksi talán tovább megy kicsit, de lehet, hogy nem.
Nekem ext4 van rajta.

U-dash
----
Frugalware 1.3
MSI MegaBook S271 + Intel SSD \m/

( Proci85 v | 2012. 06. 06., sze – 01:32 )

Ha ext4 megkapta a discard fstab opciót, akkor miért nincs trim?
Ezen teszt szerint nincs: http://techgage.com/article/enabling_and_testing_ssd_trim_support_under… 


# uname -a
Linux Dell-D630 2.6.32-41-generic #89-Ubuntu SMP Fri Apr 27 22:22:09 UTC 2012 i686 GNU/Linux

Device Model:     SAMSUNG SSD 830 Series
Serial Number:    S0VXNYAC200188
Firmware Version: CXM03B1Q
User Capacity:    64.023.257.088 bytes

# tune2fs -l /dev/sda2
http://pastebin.com/5xnV6yDb

Nem működik 2.6.35, 2.6.38, 3.0.0 alatt sem.

Erősen citation needed, de Ubuntu 10.04 alatt nekem sem működött az általad is említett leírás (újabb kernelekkel sem), de 12.04-től minden konfigurálás nélkül jó volt. De ezt most csak emlékezetből írom, majd ha eljön a 12.04-es frissítés, akkor újra beszámolok a tapasztalatokról, ha addig meg nem oldod :-)

Köszi, most felkerült a 12.04, valóban megy, + tune2fs-sel is be lehet adni egy discard flaget, hdparm vissza is igazolja, hogy van TRIM. Szóval ez kipipálva.

Ha 64GB-s SSD-ből csak a felére van szükségem (jobbára annyira sem), akkor mi jobb?
- 32GB-s partíció formázva, használva, másik fele inaktívan hagyva
- 64GB-s partíció,félig tömve?

Marad a 10.04, mert több dolog nem megy jól nálam a 12.04 + Trinity kde3 rendszerrel.
A 10.04 alatt így tovább próbálgatom az SSD témát. Alapból 2.6.32-es kernelt adja, amivel nem megy a TRIM.
2.6.35 alatt az ismert teszt szerint működik az automatikus TRIM, ámbár az fstrim -v / parancsra "fstrim: FSTRIM: Inappropriate ioctl for device"
2.6.38 alatt semmi.
3.0.0-28-as kernel még elérhető a 10.04 alól, azzal úgy tűnik, hogy ismét működik a TRIM. Az fstrim parancs is beszédesebb, bár az sem tűnik 100%-osnak, ugyanis egymás után többször futtatva ugyanannyí tisztíott blokkot jelez. Ubuntu 12.04 alól az első futtatáskor ugyanúgy kiírja, de ismét futtatva már 0 tisztítandó blokkot ír.
Szóval 10.04 + 3.0 kernellel vagy lassabban dolgozik a TRIM vagy nem is csinál semmit :)

Mindenesetre 2.6.35 alól a fenti teszt nyugtázza a háttérben munkálkodó TRIM-et, így remélhetőleg jó lesz.

Az viszont furcsa, hogy egyik verzióban előjön (2.6.35), másikban meg eltűnik a TRIM támogatás (2.6.38).

( mr shadow v | 2012. 06. 21., cs – 20:38 )

feliratkozás
--
"'The time has come,' the Walrus said"