SSD-re költözés tapasztalata

Az éjszaka egy munkagép kapott az eddigi 4 GiB helyett 8 GiB RAM-ot, egy 128 GB-os SSD-t, egy nVidia kártyát. Eddig alaplapi Radeon volt használva. Az oprendszer 64 bites Fedora 20, újratelepítést szerettem volna megúszni, egyébként sikerült is. Látszólag igen könnyű egy ilyen költöztetés, de azért vannak buktatói.

Beépítve az alkatrészek, BIOS-ban kitiltva az alaplapi VGA, majd boot. RAM megvan, hurrá. SSD partícionálása a javasolt módon, laphatár, miegymás. Hagytam partícionálatlan szabad helyet, sokat. Az sdb1 4 GiB a /boot-nak, az sdb2 60 GiB a /-nek, amin csak az oprendszer lesz, ez LVM. Utána pvcreate, vgcreate, lvcreate, laphatárra alignment, majd ext4-re formázás. /boot remount readonly, majd rsync -avHAX HDD-ről SSD-re a /boot-ot. Az SSD-t noatime,discard opciókkal csatoltam.

A zsebemben pendrive-on mindig van egy 32 bites saját készítésű live, erről boot, majd rsync-kel HDD-ről SSD-re másoltam a rootfs-t. Ez nem tartalmazza a /home-ot, /var-t, /boot-ot. Értelemszerűen nem beszélek a /dev, /proc, /media, /run, /srv, /sys, /tmp könyvtárakról, hiszen természetesen üresek.

Az SSD-n a /etc/fstab-ban a rootfs és /boot eszközfile-ok módosítása, utóbbihoz uuid lekérdezése blkid-vel, előbbinél lvm névvel hivatkozás, valamint SSD-nél noatime,discard mount opciók.

/boot/grub2/grub.cfg file-ban uuid-ek cseréje, kernelparaméterek között rootfs-re hivatkozás cseréje, Grub szerint disknevek, partícióhivatkozások cseréje, BIOS-ban az új boot device megmondása.

Na, itt nem vettem észre, hogy a HDD-n GPT volt, míg az SSD-t fdisk-kel partícionáltam, így sima MBR lett, a Grub meg más modult használ GPT-hez, mint MBR-hez.

Ezek után grub2-install, mondja, sikerült, akkor hát reboot, aztán ad a Grub egy promptot. Azért, amit az imént írtam, a konfigban gpt volt, de msdos - tehát MBR - kellett volna. Itt hiba keresgélése, töprengés, homlokra csapás, megoldás. Például úgy, hogy az elején 'e'-t nyom az ember, kézzel szerkeszti a Grubnak szánt konfigot, F10-zel boot, nem megy, újragondol, módosít, stb.

Végre berántja a kernelt, initrd-t, elindul, pár [  OK  ] után megáll, se előre, se hátra, de nincs megfagyva. Viszont addig nem jutott, hogy konzolom lehessen. Tippem, hogy akkor ez vagy SELinux, vagy initrd. Live boot-ol, a rootfs-re tettem egy .autorelabel file-t. Indítom, a jelenség ugyanaz, az újracímkézésig sem jut el. Tehát jó eséllyel initrd. Ahhoz kell dracut, meg az oprendszer működve, de épp az nem indul. Jaj!

Akkor hát próbálom chroot-tal a dracut-ot. Viszont a live Linuxom 32 bites, hogy régi gépen is menjen, ez most hátrány, mert a bash a chroot-olt környezetben 64 bites. Jó, akkor letöltök egy 64 bites live Fedorát, dd-vel pendrive-ra írom az image-et, boot-olok róla.

Itt felcsatolom egy-egy könyvtár alá az SSD-n lévő /boot-ot és /-t, majd, hogy a dracut jól lássa a / alatt a /boot-ot, még egy mount --rbind is kell. Utána chroot-tal dracut imagenév kernelverzió. Pampog, hogy nincs /proc, /dev, de valamit csinál, a keletkezett image kb. 4-szer nagyobb az eredetinél. Filerendszerek lecsatolódnak, boot... és elindul, mert megcsinálja a SELinux újracímkézést, automatikusan reboot-ol, megint elindul, működik! :)

Akkor gyorsan ezt az initrd-t átnevezem, majd végre saját környezetben csinálok egy initrd-t dracut-tal, ez végre normális méretű lesz. Reboot, elindul, örülés, átnevezett, ideiglenes initrd törlése.

A HDD-n a régi oprendszerre lvremove, a /home-ot tartalmazó lv-re pedig lvextend -l 100%FREE, aztán az ext4 tud online resize-ot, így a /home-ot le sem csatolom, resize2fs.

Most swapoff -a, törlöm a régi /boot-ot tartalmazó, és az azt követő, swap-et tartalmazó partíciókat, majd létrehozok a szabad helyre egyetlen partíciót swap típussal. Így a régi /boot 512 MB-ját megkapta a swap. Itt mkswap, az uuid módosítása az fstab-ban, majd swapon -a.

Live-ról boot, s megnéztem, a csatolási pontok alatt ne legyen semmi. A dracut például a chroot-olt környezetben a /dev-be írt két file-t. Végignéztem, kitakarítottam a szemeteket, majd reboot az átköltözött rendszeren.

Jó, gyors, stabil.

Valahol útközben megejtettem egy grub2-mkconfig parancsot is, összenéztem az eredményt az eredetivel, ami nem tetszett, azt átírtam, így az is rendben.

Update az érthetőségért:

Régi layout:

sda - 500 GB HDD

sda2 /boot
sda3 swap
sda4 Linux LVM

LVM-en belül: /, /home, /var

Az új layout:

sda - 500 GB HDD
sdb - 128 GB SSD

sda3 - swap
sda4 - Linux LVM

LVM-en belül: /home, /var

sdb1 - /boot
sdb2 - Linux LVM

LVM-en belül: /

Ami nem swap, az ext4.

( nevergone v | 2014. 06. 02., h – 14:34 )

Jó kis leírás, köszi! A mai SSD-knél is fontos még szabad helyet hagyni (teljesítményromlás, élettartam), vagy már megoldják maguk? Egy Samsung 840 EVO 250GB-t néztem ki magamnak.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

( log69 | 2014. 06. 02., h – 19:42 )

Minek az LVM? Nem lesz feleslegesen rosszabb a teljesítmény?

Illetve pl. mapper device-al tudtommal nincsen TRIM funkció, ezért nem jó SSD-vel még a DM titkosítás. Azt gondolnám az LVM-nél is probléma a külön réteg miatt.

Egyik gépemen (i5, 16 GB RAM, Samu SSD) a sima blokk másoláshoz képest egy LVM + DM titkosítással ötödére! esett a teljesítmény (tudom nálad nincs titkosítás).

A grub mindig szívás, mindegy hányszor futok bele és mennyit dokumentáltam előtte, pár órát mindig szívok ;)

Illetve hagyna a franc kihasználatlan helyet azon a kicsit kapacitású disken, én mindig lepartícionálom az egészet, aztán évek óta jól muzsikálnak - semmi teljesítmény romlás, pedig tesztelem visszatérően. ;)

Valóban, friss Fedora a kérdés, én meg El 6-ot futtatok a gépemen. Rémlik is hogy beszéltünk erről.

És valóban, habár biztonsági kockázatnak vélik:

https://code.google.com/p/cryptsetup/wiki/DMCrypt

Optional parameters

allow_discards: Allow block discard requests (a.k.a. TRIM) for the crypt device.
The default is to ignore discard requests.
Assess the specific security risks carefully before enabling this option. For example, allowing discards on encrypted devices may lead to the leak of information about the ciphertext device (filesystem type, used space etc.) if the discarded blocks can be located easily on the device later.
Available since: 1.11.0 (kernel 3.1)

3.14.4-es kernelről van szó, de lehet, holnap már 3.14.5-ös lesz rajta, frissíteni tudok távolról. :) Szóval szerintem ezek már meg vannak oldva.

Ugyan nem ástam bele magam az LVM mélységeibe, de valamilyen szinten egyfajta címfordításnak képzelem ezt. Az lv adott címéből következik, melyik vg, abból a címből kijön, melyik pv, melyik partíció melyik LBA című szektora. Ez nem tűnik túl sok számolásnak, és nem byte-onként kell számolni, hanem gondolom, physical extent a legkisebb egység, de szektornál semmiképp sem lehet kisebb. Így aztán néhány regiszterben elvégezhető aritmetikai műveletet kell végezni néhány megabyte-onként, ami nem hinném, hogy felzabálja a gépteljesítményt. A DMA kontrollert is fel kell programozni, az is belefér valahogy. :)

Az LVM-et azért szeretem, mert rugalmas. Jelen példában, amikor a HDD-ről lekerülő rootfs helyét odaadtam a /home-nak, partíciók esetén szívás lett volna. Ha egymás mellett van a / és /home, még csak-csak megoldható, de ha közte van még valami, akkor úgy lehet, hogy felírom a partíciók kezdetét, hosszát, törlöm az egész partíciós táblát, kialakítom a megfelelő sorrendben az új layout-ot a nyerő számok figyelembevételével, a HDD-n szektorosan a megfelelő helyre másolom a tartalmat, majd átméretezem a filerendszert. Ha ebben egyetlen alkalommal sem számolom el magam, s mindent jól csinálok, akár működhet is, de a legapróbb hiba, s oda minden adat.

Grubtól én is tartottam kicsit, mert nagyon okos ugyan, de azt nem tudhatja, mit forgatok a fejemben. Aztán, ha GPT-ről MBR-re teszi a dolgait az ember, akkor külön kellemetlen. Ha időben eszméltem volna, az SSD-re is GPT-t csinálok, de nem volt kedvem elölről kezdeni, előnnyel nem igen járt volna.

A hely nem volt érdekes, lényegében egy 32 GB-os, de talán még egy 16 GB-os SSD is elég. Az élettartam miatt úgy döntöttem, változó dolgok, mint amilyen a /var, /home, továbbra is HDD-n maradnak. Így csak a frissítés miatt lesz írva az SSD, normál esetben csak olvasva lesz. A noatime opciónak is ez az oka.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mert van hely sok, és ez a szám jutott elsőre eszembe. :) Mondom, egy 16 GiB-os SSD is elég lenne. Ténylegesen az oprendszer jelen pillanatban 5.4 GiB-ot, míg a /boot-on a kernel meg a grub 53 MiB-ot foglal. Persze kell hely több kernel image-nek a frissítéshez. Most még a 3.14.4-es fut, de távolról épp az imént tettem fel rá a 3.14.5-öst, tehát ebben az 53 MiB-ben két image van benne. Következő boot alkalmával már az új kernel indul.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE