💾 Archived View for gemlog.blue › users › berus › 1706544628.gmi captured on 2024-05-10 at 16:44:01. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2024-02-05)

-=-=-=-=-=-=-

Egy kis Linux és SSD összefoglaló, ahogy én szoktam (tehát nem biztos, hogy így a legjobb, mindenki csak saját felelősségre).

Particionálás:

===

Érdemes a GParted programmal csinálni (több LiveCD-s terjesztésen

megtalálható, GParted Live, SysRescueCD, stb.) így biztosan jó lesz az alignálás, alapból helyesen ajánlja fel. Lényeg, hogy az első partíciónak a 2048-as szektornál kell kezdődnie!

Alignálás ellenőrzése:

blockdev --getalignoff /dev/sda

Ha jó az alignálás 0 értéket kell kapnunk.

Ezenkívül használhatjuk a parted program align-check parancsát is.

Ne feledjük, minél több helyet hagyunk szabadon a meghajtón, a vezérlő annál jobban érzi magát!

Hogy a szabad hely particionált terület-e vagy sem, a vezérlő számára teljesen mindegy!

• **

Fájlrendszer, TRIM, ütemező:

===

A TRIM-nek két megvalósítása van Linuxon, az /etc/fstab fájlba írt discard csatolási opció, ill. az fstrim parancs.

A discard hatására az OS közli a vezérlővel, hogy az adott adat

logikailag már nem létezik, valósan törölhető, a blokk felszabadítható.

Régebbi meghajtóknál ez azonnal végrehajtódik, ezért sok kis fájl esetén teljesítmény problémákat okozhat. Az újabb "queued TRIM" (SATA rev. 3.1) eljárást ismerőknél viszont a blokkok felszabadítása nem (feltétlen) történik meg azonnal, a teljesítmény csökkenés veszélye kevésbé áll fenn.

Discard az /etc/fstab fájlban (példák):

UUID=f0ae2c59-83d2-42e7-81c4-2e870b6b255d / ext4

discard,errors=remount-ro 0 1

/dev/sda1 / ext4 defaults,noatime,discard 0 1

Az fstrim parancs megvizsgálja a meghajtót, és alapértelmezésben az összes felszabadítható blokkot "törli".

Tipikus formája:

fstrim -v /csatolási pont

Kiadható manuálisan, de célravezetőbb boot szkriptbe (pl.

/etc/rc.local) tenni, vagy cron feladatot létrehozni belőle, napi vagy heti futtatással.

Néhány újabb systemd-t használó terjesztésben (pl. Fedora 24) elérhetőek az "fstrim.service" és az "fstrim.timer" egységek.

Engedélyezés (alapértelmezésben hetente fut le):

systemctl enable fstrim.timer

Hogy melyiket érdemes használni a discard és az fstrim közül, azt

nagyban befolyásolják a felhasználói szokások, a kernel verziója, és a meghajtónk képességei.

Jelenleg a következő Linuxos fájlrendszerek támogatják a TRIM funkciót: EXT4, Btrfs, JFS, XFS, F2FS, Reiser4.

Bizonyos szerencsétlen összeállításoknál a "queued TRIM" eljárás (tehát a discard opció) problémákat okozhat!

Ennek oka a hibás eszköz firmware (pl. bizonyos Samsung meghajtók).

Kerülő megoldásként ezek a meghajtók feketelistára kerültek a

kernelben, és hagyományos, azonnal végrehajtódó TRIM parancsot kapnak. Erre érdemes lehet figyelni!

Érdemes lehet az I/O ütemezőt cfq-ról (ami figyelembe veszi a HDD

olvasó/író fej helyzetét) deadline-ra, ill. csak SSD használata esetén noop-ra állítani.

Jelenlegi ütemező lekérdezése (adott meghajtó):

cat /sys/block/sda/queue/scheduler

Összes meghajtó lekérdezése:

for f in /sys/block/sd?/queue/scheduler; do printf "$f -> "; cat $f;

done

Az ütemezőt legegyszerűbb az /etc/default/grub fájl megfelelő sorának módosításával állítani (példánkban deadline-ra):

GRUB_CMDLINE_LINUX_DEFAULT="elevator=deadline quiet splash"

Majd futtassuk az update-grub parancsot! A beállítás a következő

rendszer töltéskor lép érvénybe.

LILO használata esetén adjuk az /etc/lilo.conf fájlhoz a következő sort:

append="elevator=deadline"

Majd futtassuk a lilo parancsot.

Ha HDD is van a gépünkben, és más-más ütemezőt szeretnénk az SSD-nek és a HDD-nek, akkor a megfelelő UDEV .rules fájlok létrehozásával beállíthatjuk.

Hozzuk létre az /etc/udev/rules.d/60-sda_sdb.rules fájlt az alábbi tartalommal:

# set noop scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0",
ATTR{queue/scheduler}="noop"
# set cfq scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1",
ATTR{queue/scheduler}="cfq"

Ha csak az SSD meghajtóknak akarunk udev szabályt (/etc/udev/rules.d/90-iosched.rules):

# set noop scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", SUBSYSTEM=="block", ATTR{queue/scheduler}="none"

Ugyanezt elérhetjük az /etc/rc.local fájl módosításával is:

echo noop >/sys/block/sda/queue/scheduler

echo cfq >/sys/block/sdb/queue/scheduler

• **

Egyéb ötletek:

===

A meghajtó kímélése és a teljesítmény növelése miatt fontos lehet a noatime csatolási opció beállítása az /etc/fstab fájlban, így nem kerül kiírásra az utolsó fájlhozzáférés időbélyege. Hasonló okokból használhatjuk a nodiratime opciót is.

Ha a swap SSD-re kerül, próbáljuk csökkenteni a swap használatot a swappiness érték (alapértelmezésben 60) csökkentésével.

Ehhez írjuk az alábbi sort az /etc/sysctl.conf fájlba:

vm.swappiness=10

Az újabb rendszereknél:

echo "vm.swappiness=10" > /etc/sysctl.d/100-swpn.conf

Az értéket érdemes magunknak kikísérletezni, akár 0-ra is állíthatjuk.

Ha a swap az SSD-re kerül, megfontolandó swap partíció helyett swap fájl használata!

Swap fájl létrehozása:

fallocate -l 1024M /swapfile

vagy

dd if=/dev/zero of=/swapfile bs=1024 count=1048576

Engedélyek:

chmod 600 /swapfile

Fájlrendszer létrehozása:

mkswap /swapfile

Indítsuk el:

swapon /swapfile

Bejegyzés az /etc/fstab-ban:

/swapfile none swap defaults 0 0

Készen vagyunk.

A meghajtón rendben van-e a TRIM:

hdparm -I /dev/sda | grep TRIM

Válaszként ezt kell látnunk: "Data Set Management TRIM supported (limit 1 block)".

Egyéb lehetőségek:

cat /sys/block/sda/queue/discard_max_bytes

Ha eredményként 0-át kapunk, nem működik a TRIM.

lsblk -D

Ahol a DISC-GRAN és DISC-MAX értéke 0, ott nem működik a TRIM.

SATA mód ellenőrzése:

smartctl -a /dev/sda | grep SATA

Válaszként ezt kell látnunk: "SATA Version is: SATA 3.0, 6.0 Gb/s

(current: 6.0 Gb/s)".

A smartctl parancs a SMARTmontools csomag része.

Ezenkívül érdemes a /tmp könyvtárat tmpfssel (átmeneti fájlrendszer, ami sosem íródik lemezre) a

RAM-ba rakni (ezt néhány terjesztés alapból megteszi).

Ehhez az /etc/fstab fájlba írjuk a következő sort:

tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0

Systemd-t futtató rendszereknél eljárhatunk így is:

cp -v /usr/share/systemd/tmp.mount /etc/systemd/system/

systemctl enable tmp.mount

Esetleg telepíthetjük a preload programot. Ez igyekszik megtanulni a leggyakrabban használt programokat, és előtölti őket a memóriába.

• **

Példák:

===

Fstrim parancs az /etc/rc.local fájlban (így minden rendszer töltéskor lefut):

#!/bin/sh -e
#
# rc.local
#
fstrim -v /csatolási pont
exit 0

Ha adott csatolási ponton szeretnénk futtatni (naplózással) cron

feladatként, hozzunk létre egy fstrim nevű fájlt:

#!/bin/sh
LOG=/var/log/fstrim.log
echo "* $(date -R) *" >> $LOG
fstrim -v /csatolási pont >> $LOG

Ha több csatolási ponton akarjuk végrehajtani (példánkban / és /home):

#!/bin/sh
# Az SSD_MOUNT_POINTS változóban sorold fel a csatolási pontokat.
# Elválasztónak használj szóközt.
LOG=/var/log/fstrim.log
SSD_MOUNT_POINTS='/ /home'
for mount_point in $SSD_MOUNT_POINTS
do
echo "* $(date -R) *" >> $LOG
fstrim -v $mount_point >> $LOG
done

Tegyük a fájlt futtathatóvá és másoljuk a megfelelő /etc/cron.daily vagy /etc/cron.weekly könyvtárba.

• **

Cron feladatként futó, ill. a systemd által meghívott fstrim naplózása:

Először is szükségünk van a syslogra, telepítsük és futtassuk, ha eddig nem tettük volna, majd a cron/systemd szkriptben

(/etc/cron.weekly/fstrim, ill. /usr/lib/systemd/system/fstrim.service)

szereplő fstrim parancsot egészítsük ki a "-v" kapcsolóval.

Ezek után a syslogban (ill. bizonyos rendszereknél a

daemons/info.log-ban) ellenőrizhetjük az fstrim sikeres lefutását.

Systemd-t használó rendszereknél nincs feltétlen szükség syslogra, az alábbi paranccsal is ellenőrizhetjük a

sikeres végrehajtást:

journalctl -u fstrim

• **

A példákban feltételezzük, hogy az SSD az első meghajtó a rendszerben, tehát a /dev/sda!

A módosításokhoz root jogokkal kell rendelkeznünk!

Más-más terjesztéseknél változhatnak a fentebb említett fájlok elérési útjai és szintaktikái!

Irodalomként az Arch Linux idevágó wiki oldalát ajánlom!

[Frissítve 2022 máj.]