Költözés SSD-re (Kingston UV400 120GB)

 ( Anonymous | 2016. november 8., kedd - 16:46 )

Üdv. Mindenkinek!
Az SSD használatról szóló rengeteg topik átolvasása után a véleményeteket szeretném kikérni a "jó" fstab beállításaival kapcsolatban.Telepítés után ez az origi fstab:

UUID=0a9def28-763f-4b00-b549-244ee66f45a1 / ext4 noatime,errors=remount-ro 0 1
# /home
UUID=1c4b7ed2-453e-42ce-baf0-12e1a23e5ffa /home ext4 noatime 0 2
# SWAP
UUID=e0c2e554-9a08-44c0-ba14-c685ecd39e2f none swap sw 0 0

Majd így módosítanám:

UUID=0a9def28-763f-4b00-b549-244ee66f45a1 / ext4 noatime,discard,errors=remount-ro 0 1
# /home
UUID=1c4b7ed2-453e-42ce-baf0-12e1a23e5ffa /home ext4 noatime,discard,errors=remount-ro 0 2
# SWAP
UUID=e0c2e554-9a08-44c0-ba14-c685ecd39e2f none swap sw 0 0

A rendszer normál bios-os gépen van mbr partíciós táblával. Az OS Debian 8 stable alapú SolydK 64bit, 3.16.0-4-amd64 kernellel.
Ajánlások alapján az SSD-t úgy partícionáltam, hogy a partíciós tábla végén hagytam 5%-nyi 6GB partícionálatlan területet.

Disk /dev/sda: 111,8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x000c4a2b

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 73402367 73400320 35G 83 Linux
/dev/sda2 73402368 213471231 140068864 66,8G 83 Linux
/dev/sda3 213471232 221859839 8388608 4G 82 Linux swap / Solaris

Kell-e az fstab-ba a discard opció, vagy hagyjuk a rendszerre a trimmelést, ha igen, azt hol találom pontosan?

Minden ötletet és javaslatot szivesen várok.
Elóre is köszi Mindenkinek.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Vagy discard, vagy fstrim cron-ból futtatva, de több helyen olvastam hogy inkább az a fstrim az ajánlott..
Azt még megnézheted esetleg hogy a partíciók "illesztve vannak-e" (aligned, a parted progival)..
--
God bless you, Captain Hindsight..

Pontosabban hogyan tudom megnézni a partíciók illesztését? Az fdisk -l kimenetből nem látszik? Bevallom ilyenekkel még nem foglalkoztam.

................

Úgy néz ki, hogy OK.

tesztssd@kingstoneuv400 ~ $ sudo parted /dev/sda
[sudo] password for tesztssd:
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: ATA KINGSTON SUV400S (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
1 1049kB 37,6GB 37,6GB primary ext4 boot
2 37,6GB 109GB 71,7GB primary ext4
3 109GB 114GB 4295MB primary linux-swap(v1)

(parted) align-check opt
Partition number? 1
1 aligned
(parted) align-check opt
Partition number? 2
2 aligned
(parted) align-check opt
Partition number? 3
3 aligned
(parted)

Tökéletes..
--
God bless you, Captain Hindsight..

Ha esetleg egyforma HDD-k vannak, akkor ez segíthet még, mert mutatja a SERIAL-t is:

sudo lshw -c disk

Köszi.

Jó lesz az, mehet rá a periodic trim is.
De alapvetően nem kell aggódni érte, általános kihasználtságú gépen nem a cellafáradástól fog tönkremenni.

A fentihez, itt is írnak róla: https://wiki.archlinux.org/index.php/Solid_State_Drives#Continuous_TRIM

+1
Ja még valami, a grub konfigjába állítólag mehet az "elevator=deadline" a noop vagy a cfq helyett..
De valaki majd megcáfol, ha mégsem
--
God bless you, Captain Hindsight..

Egy a lényeg: a discard legyen és futtass `fstrim --all --verbose` parancsot rendszeresen, a többire felesleges időt áldozni, nem (ettől) fog tönkremenni.

Ezt a parancsot, hogyan tudom automatizálni?
Vagy a rendszer által beállított trimet hol tudom megnézni?

"Ezt a parancsot, hogyan tudom automatizálni?": cron?

Majd javítsd ahol kell..

1. gksudo gedit /etc/cron.daily/trim

2. #!/bin/sh
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOG
fstrim -v /home >> $LOG (nyilván ez kerül ugye a trim-fájlba értelemszerűen, kilép, ment)

3. sudo chmod +x /etc/cron.daily/trim (ha eddig nem lett volna még futtatható)

Innen : https://turriebuntu.wordpress.com/ubuntu-pages/precise-specific-pages/using-fstrim-to-trim-your-ssd-instead-of-delete-in-fstab/
--
God bless you, Captain Hindsight..

Én azért javasolnám a --all és --verbose használatát, akkor biztos lefut minden fájlrendszeren, ahol értelme van és látod a kimenetét is... :)

Egy pár napig jegelem a témát idő hiánya miatt és a cron-nak is utána szeretnék olvasni.
Köszöm a segítséged és a többiekét is.

Annyi változás történt az eredeti állapottal kapcsolatban, hogy most Ubuntu 16.04 van az SSD-n. A különbség a Debian 8-hoz képest az, hogy az Ubi automatikusan létrehozta a "/etc/cron.weekly/fstrim" állományt. A következő paraméterekkel:

#!/bin/sh
# trim all mounted file systems which support it
/sbin/fstrim --all || true

Lejjeb ajánlottátok a --verbose kapcsolót is az fstrimm-hez, ami a trimmelés eredményét írja ki log-ba.

Lehet-e a log fájlt átirányítani, mondjuk ide?
-/home/felhasználó/SSD Trimmelés (ezt én hoznám létre, hogy ne a /var/log-ban keljen túrkálni)

Maradjon a weekly-ben vagy legyen napi futású?

Másik különbség a fstab-ban mutatkozik a két rendszert alapul véve.
-Jessie, "noatime" kapcsoló csak a gyökér partíció-ra
( ha csináltunk külön /home partíciót arra már nem )
A cron-ban nincs "fstrim" állomány
-Ubi 16.04, a partíciókra nem állít be sem "discard" sem "noatime" kapcsolókat, viszont heti lefutású "fstrim"-et "--all" kapcsolóval.

Most úgy áll a dolog, hogy az fstab-ban beállítottam a "noatime" és "discard" kapcsolókat is és van az alapbeállítású heti trimm.

Szerintem kar vele bibelodni, jo az ahogy az Ubuntu alapbol megcsinalja (fstrim futtatasa hetente).

A discard-ot ne állítsd be az fstab-ban, csak az fstrim-et használd kb. heti ütemezéssel.


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

Lenne egy kérdésem. A discard és az fstrim összeakadhat?
Tegnap reggel akartam módosítani az fstab-ot ( kivenni a discard-ot) és az fstrim-be berakni a --verbose opciót.

A gépem rendszerfrissítéssel kezdett ( Firefox és pár kisebb komponens, kb.:50MiB letöltendő cucc). Jól van menjen leokéztam. Közben mehet a saját dolgom is. Ekkor tapasztaltam, hogy a letöltési folyamat is és a telepítési folyamat is lassabb a megszokottnál. Továbbá a rendszer is sokkal lassabban reagál a megszokottnál. Ezt úgy értem, hogy a keresőbe írt kifejezésre is lassabban reagált a rendszer és a grafikus felület is belassult. Nem mondom, hogy lefagyott a rendszer, mert az egér pl. rendesen mozgott.
Nem erőltettem a dolgot, kivártam türelemmel a frissítést, majd restart. Aztán minden normálisan működött. Elvégeztem a szükséges módosításokat.

A heti futású fstrim a hét melyik napján fut?
Amikor fut, azt érzékelhetem-e?
A rendszerindításhoz képest mikor fut?

A --verbose kapcsoló beállításával a következő alkalommal jön létre a log kimenet a trimmelésről?

Véleményem szerint azért célszerűbb az ütemezett fstrim az fstab-ba írt discard-nál, mert jobban kíméli az SSD-t. Ha túl gyakran törlöd fizikailag a blokkokat, azzal csökkented az élettartamot. Ugyanakkor a sebesség szintentartása miatt, tehát, hogy ne kelljen a filerendszerben felszabadított blokkokat is cache-be olvasni, módosítani, visszaírni, szükség van a TRIM-re. De nem mindig, elég hetente. Ennyi időn belül nem lesz érzékelhetően sok felszabadított, de fizikailag nem törölt blokk, így a sebesség nem romlik, de ha nagyon ráfeszülsz a kérdésre, akkor viszont csökkented az élettartamot.

A discard-ot és fstrim parancsokat nem használnám egyszerre. Szerintem nem akadhat össze, de az csak az, amit erről gondolok.

A heti futású fstrim a hét melyik napján fut?

Attól függ, hogyan oldod meg. A crontab-ba írod, akkor azon a napon, amelyet a bejegyzésben előírsz neki. Nekem systemd unit van hozzá Fedorán, fogalmam sincs, meg kellene néznem a dokumentációt. Amúgy meg nem teljesen mindegy?

Amikor fut, azt érzékelhetem-e?

Szerintem átlagos felhasználásnál nem, de el tudom képzelni, hogy nagy mennyiségű adat mozgatása lassabb lehet ilyenkor.

A rendszerindításhoz képest mikor fut?

Amit a konfigurációs állományban mondasz neki. Nálam van egyfajta „lötyögése” ennek, nem fix időpontban indul a boot után. Lásd még a systemd.timer AccuracySec paraméterét!

A --verbose kapcsoló beállításával a következő alkalommal jön létre a log kimenet a trimmelésről?

Amikor legközelebb fut. A múltról már nem tud logot írni. :)


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

Köszönöm.

Nem akadhat.
Nyugodtan használhatod a discardot, a modern meghajtók/vezérlők az un. queued TRIM eljárást használják, tehát nem "törölnek" azonnal. Gyk. a discard egy jelzést ad a vezérlőnek, hogy a blokk logikailag már nem létezik, felszabadítható, a vezérlő meg foglalkozik vele, amikor jónak látja...

Amúgy írtam a témában egy kis szösszenetet, ha érdekel olvashatod itt:
https://logout.hu/bejegyzes/berus_berus/linux_es_ssd_gyorstalpalo_2.html

> BERUS
Motor: Mageia 5.1; BunsenLabs Linux Hydrogen; Debian GNU/Linux Jessie; Windows Phone 10

Köszönöm, a linket is. Szeretnék minél több anyagot elolvasni a témában, hogy jobban megismerjem.

Természetesen nem a blokk, hanem a rajta lévő adat nem létezik logikailag, bocsi...

> BERUS
Motor: Mageia 5.1; BunsenLabs Linux Hydrogen; Debian GNU/Linux Jessie; Windows Phone 10

Én is elolvastam, helyeslően bólogattam. :)


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

sub

+1

Felesleges particionálatlan területet hagyni, elég figyelni, hogy legyen elég üres hely, mivel a vezérlőnek teljesen mindegy, hogy a terület particionált-e vagy sem.

> BERUS
Motor: Mageia 5.1; BunsenLabs Linux Hydrogen; Debian GNU/Linux Jessie; Windows Phone 10