#2

Ahogy fentebb kifejtettem, nekem nem valószínű, hogy az SSD kicsi lesz, de annyit simán be tudok vállalni, hogy 3 rendszer helyett csak 2-t telepítek, bár ahogy írtam, esetemben, ha csak a rendszer használná (a /home gyakorlatilag üres lenne rajta, az adattárolás egy másik Adat partíción valósulna meg elkülönítve, ahogy jeleztem a téma felvetésekor) elviekben elégnek kellene lenni bőven 50 GB-nak (, ha csak 2 lesz, akkor meg jut 75 GB-is darabonként+jut hely az apróságoknak, a 4 GB SWAP-nek, meg úgy 100 GB az Adatnak).

Akkor nekem csak a SWAP partíció lesz a jó (amúgy is ez irányba hajlok), mert a fájl nem játszik 2, vagy több rendszer esetén, jó ezt is tudni.

Az SSD optimalizálása témában már kiokosítottatok korábban (https://linuxmint.hu/forum/igazhamis-3-gb-ddr2-667-mhz-memoria-integralt-gpusok-swap-hasznalatssdido-elotti-karosodasok), de azért köszönöm, hogy ezt is megemlítetted (már be volt állítva).

A BIOS boot partíción én sem sokat aggódom (jeleztem is fentebb, a téma felvetésekor, hogy tőlem elfér, ha nem okoz gondot), a mérete viszont nem a véletlen műve (biztosra akartam menni, hogy elég lesz, nehogy kifussak belőle egy nagyobb igényű disztró, vagy amiatt, hogy több rendszer kerül a gépre és mindegyik használná), ebből inspirálódtam, bár lehet, hogy az értelmezés, kivitelezés nem volt tökéletes (https://medium.com/@manujarvinen/setting-up-a-multi-boot-of-5-linux-distributions-ca1fcf8d502(külső hivatkozás)):

„In my first tests I made it less than 100 MB in size, but on my later partition setup I made it 1000 MB because I noticed some distros like Deepin(külső hivatkozás) need more than 100 MB for the EFI partition. 1 MB of free space will be created automatically out of the first partition you create. It’s for SSD alignment, which is important for keeping the SSD speeds up, I was once told. The second bios boot partition was required by some distros, like Fedora(külső hivatkozás). I left it unformatted for now, but in future I might need it if I install Fedora. It could’ve been left way smaller, like even 1 MB (see below the Fedora message image), but I went with 1000 MB, just in case. Naturally, this can be also resized afterwards, if needed.”

Megkísérelem majd az UEFI-s bootolást, úgy sejtem, hogy ezt a BIOS-ban történő CSM kikapcsolásával fogom tudni elérni (azért majd jobban szemügyre veszem a pontos lehetőségeimet). Abból következtetek erre, hogy mikor korábban kikapcsoltam (a téma felvetésekor megemlítettem), akkor nem indult a rendszer, így gondolom, ennek a ki-be kapcsolásával tudok váltani az UEFI/BIOS között.

Van nekem is 120 GB-os SSD-n rendszerem, de tudom, hogy azt böngészésen kívül nem nagyon használom semmire, adattárolásra biztos nem. Nagyon picik ezek a rendszerpartíciók, hamar betelhetnek. Én biztos nem tennék fel ennyi rendszert ide, legfeljebb egyet, maximum kettőt. Ha csak egy rendszered van, akkor nem kell, hogy a swap partíció legyen, akkor nyugodtan lehet swapfájl is. Azt nem muszáj előre létrehozni, nyugodtan lehet utólag, vagy lehet törölni, helyette újat létrehozni, másik partíción létrehozni...
Ha két vagy több Linuxot teszel a lemezre és KELL (kell?) a swap, akkor viszont az inkább legyen partíció, mert akkor azzal csak egyszer foglalod a helyet a lemezen. (Minden telepített Linuxon állítsd át a swappiness értékét az alapértelmezett 60-ról 10-re, hogy feleslegesen viszont ne irkáljon az SSD-re a rendszer!)

Az 1 MB-os formázatlan BIOS boot partícióval nem tudom miért foglalkozol annyit. Az az 1 MB nem hiányzik sehonnan. Ha használja a rendszer használja, ha nem hát nem. De az 1MB az legyen 1 MB, teljesen felesleges a 1000 MB.

UEFI módban bootolj a telepítőről és UEFI-s lesz a telepítésed is (a BIOS-ban a CSM-et akár ki is kapcsolhatod, hogy csökkentsd a Legacy boot esélyét).

#7

EFI: Megfogadom a tanácsokat.

SWAP: nem hibernálok, nem használok erőforrás igényes alkalmazásokat (eddig legfeljebb 3 GB körüli a RAM használatom, ami vicc kategória), a géphez elvileg 8 GB memória járt volna (nekem ez is több, mint elég lenne), de az eladóval megdupláztattam 16 GB-ra, hogy bőven bebiztosítsam magam (az általam választott és használt 4 GB-os swap-méret egyébként nem saját ötlet, ebben a korábbi kommentemben említett videó volt a kiindulási pont: https://linuxmint.hu/comment/39644#comment-39644).

EFI: köszönöm a tippet, úgy látszik, itt még a biztonságosnak tűnő 1 GB is kevés

Valójában az 512 MB is bőségesen elég lenne, viszont vannak rendszerek, amik alapból nagyobbra készítik el (például a PopOS ha jól emlékszem 2024 MB-ot vár alapból), ezért a későbbi eshetőségekre felkészülve érdemes nagyobbra méretezni.
A Gparted-del is meg lehet csinálni, nincs azzal semmi gond, de telepítés közben egyszerűbb és úgy biztosan jó lesz. Gparted-del egy FAT32-es partíció kell (vFAT), aminek a flag-jét ESP-re kell beállítani (korábban már leírták ezt). Más nem is nagyon kell.
Több rendszer telepítése esetén is csak egy EFI partíció szükséges!  (Ha Windows-t is telepítenél, az úgy huncutabb dolog, de jelen esetben most ez úgy látom nem kell).

Swap. Nincs itt kőbe vésve semmi, viszont, ha a példa kedvéért hibernálni is kellene a rendszert, akkor 8GB fizikai memóriánál egy 4GB-os swap már kevés lesz, ha 6GB van használatban. Egyébként persze: ha memóriaigényes alkalmazásokat használ a felhasználó, akkor vegyen fizikai memóriát, mert a swap eleve egy kényszer megoldás a kevés memóriára.

 

Sziasztok!

Említettem korábban, hogy több rendszert szeretnék telepíteni a gépeimre, a régi AlbaComp-ra már fel is küzdöttem két linuxot (a témához kapcsolódó témaindító bejegyzésem OFF részében írtam erről a szándékomról is), tudom, hogy nem a legjobb helyen teszem fel a kérdést, mivel egyik sem Mint, de máshol nem találtam tuti választ a problémámra, így bátorkodom hozzátok fordulni.

A partíciók jelenleg így néznek ki (amikor az ANTIX-ot futtatom):

norbi@ALBACOMP:~

$ sudo gdisk -l /dev/sda

GPT fdisk (gdisk) version 1.0.9

Partition table scan:

MBR: protective

BSD: not present

APM: not present

GPT: present

Found valid GPT with protective MBR; using GPT.

Disk /dev/sda: 500118192 sectors, 238.5 GiB

Model: KINGSTON SKC6002

Sector size (logical/physical): 512/4096 bytes

Disk identifier (GUID): 2C00770B-0B78-4EF4-A560-7DC01BD5FFE2

Partition table holds up to 128 entries

Main partition table begins at sector 2 and ends at sector 33

First usable sector is 34, last usable sector is 500118158

Partitions will be aligned on 2048-sector boundaries

Total free space is 2669 sectors (1.3 MiB)

Number Start (sector) End (sector) Size Code Name

1 2048 4196351 2.0 GiB EF00 BOOT

2 4196352 12584959 4.0 GiB 8200 SWAP

3 12584960 117442559 50.0 GiB 8300 SYS1

4 117442560 222300159 50.0 GiB 8300 root

5 222300160 500117503 132.5 GiB 8300 SHARED DATA

norbi@ALBACOMP:~

$ sudo parted /dev/sda p

[sudo] norbi jelszava:

Típus: ATA KINGSTON SKC6002 (scsi)

/dev/sda lemez: 256GB

Szektorméret (logikai/fizikai): 512B/4096B

Partíciós tábla: gpt

Lemezjelzők:

Szám Kezdet Vég Méret Fájlrendszer Név Jelzők

1 1049kB 2149MB 2147MB fat32 BOOT boot, esp

2 2149MB 6443MB 4295MB linux-swap(v1) SWAP swap

3 6443MB 60,1GB 53,7GB ext4 SYS1 legacy_boot

4 60,1GB 114GB 53,7GB ext4 root

5 114GB 256GB 142GB ext4 SHARED DATA

norbi@ALBACOMP:~

Ha minden igaz nagyjából sikerült mindent beállítanom, ami az SSD-t illeti:

NOATIME:

GNU nano 7.2 /etc/fstab I

# /etc/fstab: static file system information.

#

# <file system> <mount point> <type> <options> <dump> <pass>

 

#Entry for /dev/sda3 :

UUID=fff53c19-56eb-4aaa-a3ec-891d8eca20c9 / ext4 discard,noatime 1 1

#Entry for /dev/sda1 :

# EREDETI BEÁLLÍTÁS: UUID=9DA7-1E4A /boot/efi vfat noatime,dmask=0002,fmask=0113 0 0

UUID=9DA7-1E4A /boot/efi vfat dmask=0002,fmask=0113 0 0

#Entry for /dev/sda5 :

UUID=dff83124-6ecf-4fae-9b4b-ee66bb9ee3a0 /mnt/SHARED_DATA ext4 defaults,noatime 0 0

#Entry for /dev/sda2 :

UUID=48c16522-ebfa-4d3f-8c17-8fa328766365 swap swap discard 0 0

/dev/cdrom /media/cdrom iso9660 noauto,users,exec,ro 0 0

/dev/cdrw /media/cdrw iso9660 noauto,users,exec,rw 0 0

/dev/dvd /media/dvd udf noauto,users,exec,ro 0 0

/dev/dvdrw /media/dvdrw udf noauto,users,exec,rw 0 0

/dev/sr0 /media/sr0 auto noauto,users,exec,ro 0 0

Remélem, hogy ez a rész rendben van, bár a /dev/sda1-nél gyárilag nem a legjobb volt a beállítás (korábbi kommentem /https://linuxmint.hu/comment/39992#comment-39992 / 1.) NOATIME: pontjából kiindulva), de nyomtam neki egy #-et és alatta javítottam.

A TRIM-nél viszont elakadtam (https://wiki.archlinux.org/title/Solid_state_drive(külső hivatkozás)), a fenti fstab sorokból kitűnik, hogy elviekben a discard révén (ha jól tudom folyamatos jelleggel: https://www.digitalocean.com/community/tutorials/how-to-configure-periodic-trim-for-ssd-storage-on-linux-servers(külső hivatkozás)) futtatva van a /dev/sda3 / pratíció és a /dev/sda2 swap partíció esetén (nem vagyok benne biztos, hogy ez utóbbinál jól van ez így, mert régebben belefutottam ellenérvekbe is: https://linuxmint.hu/comment/39648#comment-39648 https://linuxmint.hu/comment/39651#comment-39651, illetve itt sem látható, hogy aktív lenne a swap esetén: 4.2. Modifying the /etc/fstab File: https://www.baeldung.com/linux/trim-ssd(külső hivatkozás)), viszont a /dev/sda5-nél nem aktív, pedig annak kellene, hogy legyen (itt opció a discard hozzáadása???), vagy mivel a /dev/sda3 alá van csatolva, így ezen is lefut???:

norbi@ALBACOMP:~

$ findmnt -t ext4 -o TARGET,OPTIONS

TARGET OPTIONS

/ rw,noatime,discard

└─/mnt/SHARED_DATA rw,noatime

norbi@ALBACOMP:~

A legjobb a discard helyett a /etc/cron.weekly/fstrim hetente történő futtatása volna (Mint esetén eddig ez volt használatban), de nem vagyok benne biztos, hogy ez esetben opció, mivel az antiX systemd mentes (ha nem tévedek ez hatással van erre a lehetőségre, mivel ebben a leírásban: https://www.digitalocean.com/community/tutorials/how-to-configure-periodic-trim-for-ssd-storage-on-linux-servers(külső hivatkozás), a Step 3 részben csak systemd-vel megáldott disztribúciókat emlegetnek).

norbi@ALBACOMP:~

$ systemctl cat fstrim.timer

ERROR:systemctl:Unit fstrim.timer could not be found.

norbi@ALBACOMP:~

Az fstrim-re rákeresve a fájlrendszerben, ezt a képet látom:

https://ibb.co/RGBzVFyy(külső hivatkozás)

csak egy futtatható fstrim fájl van a /usr/sbin mappában (esetleg ezzel tudok valamit kezdeni???).

norbi@ALBACOMP:~

$ cat /etc/cron.weekly/fstrim

cat: /etc/cron.weekly/fstrim: Nincs ilyen fájl vagy könyvtár

norbi@ALBACOMP:~

$ sudo run-parts -v /etc/cron.weekly

[sudo] norbi jelszava:

run-parts: executing /etc/cron.weekly/0anacron

run-parts: executing /etc/cron.weekly/man-db

ha minden ok lenne TRIMügyileg, akkor itt egy ilyen sornak is kellene lennie:

run-parts: executing /etc/cron.weekly/fstrim

Ha nem tévedek a /etc/cron.weekly/trim környékén kellene ügyködnöm, hogy célt érjek (6. Automating TRIM With Cron Jobs: https://www.baeldung.com/linux/trim-ssd(külső hivatkozás)). Ha minden igaz, akkor (a linkelt leírás alapján) létre kellene hoznom egy script-et (https://www.geeksforgeeks.org/how-to-create-a-shell-script-in-linux/(külső hivatkozás)) az említett elérési útvonallal (/etc/cron.weekly/trim), viszont ez már kezdi meghaladni a képességeimet, így ebben kérnék egy kis segítséget, valamint abban, hogy olyan beállításokat hozzak létre, amely a megfelelő partíciókon futtatja le hetente a TRIM-et.

Az alábbiak szerint képzelem a megoldás kivitelezését (ha fentebb tévedtem a TRIM és a systemd kapcsolatát illetően, akkor még működhet is), ezt kellene a nagyérdeműnek minősítenie (ér a tanács és a kritika is):

norbi@ALBACOMP:~

$ cd /etc/cron.weekly

norbi@ALBACOMP:/etc/cron.weekly

$ touch trim.sh

norbi@ALBACOMP:/etc/cron.weekly

$ sudo nano /etc/cron.weekly/trim

Az alábbi sorok kerülnének beillesztésre a fájlba:

!/bin/bash

# This script runs the fstrim command once a week and trims all the mounted file systems that support TRIM.

# It also appends the output of the command to the /var/log/trim.log file, which you can use to monitor the trim operations.

sudo fstrim -v --all >> /var/log/trim.log

Az (fstrim –help kimenetéből kiindulva) --all kapcsoló (trim mounted filesystems) helyett nem volna jobb a --listed-in használata (trim filesystems listed in specified files) a trimmelendő partíciók pontos meghatározása miatt (és, ha igen, akkor ezt a listát, hogyan és hol hozzam létre, illetve a scriptben miként módosítsam a parancsot)? A trim.log fájlt létre kell hoznom manuálisan (ha igen, akkor mi a recept???), vagy ez automatikusan megtörténik (valahol legbelül érzem, hogy nincs ilyen "szerencsém")?

A segítséget előre is köszönöm.

#12

Üdv!

Igazából biztonsági tartaléknak szánom, mivel elég koros már, viszont az antiX elég elfogadható teljesítmény hoz ki belőle (önmagához képest), ami meglepet és arra csábít, hogy komolyabban foglalkozzam vele.

Az elmúlt erős 10 évben Linux futott rajta, 2019-től, pár nappal ezelőttig Linux Mint 19.2 64 bit LTS+Xfce (korábban az Ubuntu 14.04 LTS+UNITY-vel is volt egy közel 5 éves kalandom). Sajnos a memória mérete és a koros hardver miatt elég gyakran vette igénybe a swap területet használat közben (Mint), ezért próbálkozom kifejezetten könnyűsúlyú disztrókkal, és eddig az antiX elég ígéretesnek tűnik, csak az SSD optimalizálása közben akadtam el egy kicsit, ahogy írtam.

Ami a hardvert illeti:

lshw: https://paste.ubuntu.com/p/GMkHSrcr2K/(külső hivatkozás)

Az SSD 2020 nyarán került beszerzésre, mivel a gyári hdd visszaadta a forgalmiját, és azóta köszöni de jól van, tehát nem egy régi, lerúgott darab (https://linuxmint.hu/forum/igazhamis-3-gb-ddr2-667-mhz-memoria-integralt-gpusok-swap-hasznalatssdido-elotti-karosodasok).

A paraméterei láthatóak a fentiekben közölt sudo parted /dev/sda p parancs kimenetében:

Típus: ATA KINGSTON SKC6002 (scsi)

/dev/sda lemez: 256GB

Részletesebben (sudo smartctl -a /dev/sda): https://paste.ubuntu.com/p/yxhQW2r3sN/(külső hivatkozás)

Ahogy írtam, a Mint esetén nem volt ilyen problémám, a megfelelő beállításokat (https://linuxmint.hu/comment/39992#comment-39992) véghez tudtam vinni, évekig gond nélkül működött is (https://paste.ubuntu.com/p/wFQf572DY2/(külső hivatkozás) ), viszont most (gyanúm szerint a systemd hiánya miatt) nem boldogulok vele:

norbi@ALBACOMP:~

$ systemctl cat fstrim.timer~

ERROR:systemctl:Unit fstrim.timer~ could not be found.

norbi@ALBACOMP:~

Remélem sikerült jobban megvilágítanom a jelenlegi helyzetemet, ha mégsem kérlek kérdezz és igyekszem pontosabban válaszolni.

#11Mit szeretnél elérni? Mármint a géppel magával. Mi volt elötte rajta, W98?, XP?

sata I a vezérlője?

Van neki 64 bites procija?

Miért kellett Mint alatt is szkripttel futtatni a TRIM-et? Talán az SSD is egy olyan régi? (Mármint az Albacomp idején még híre sem volt az SSD-nek, talán akkor volt bevezetve a SATA. 64 bites konzumer procija már volt a AMD-nek, de az nem került laptopba. Ebben valami Centrino lehet még.

Szóval, mire lehet jó egy ilyen gép, és systemd mentes linux?

#14

Azért gondoltam a heti TRIM beállítására, mert ugyanezen a gépen, LM 20-at futtatva, az SSD beszerzése óta (2020 nyara) ez a beállítás élt elviekben (Mint fórumon kapott tanácsok és egyéb netes infók alapján), így úgy sejtettem, hogy ez lesz a nyerő az antiX (, meg a Sparky) számára is, mivel a hardver változatlan.

Egyébként azt már én is észrevettem, hogy nem igazán létezik egyértelműen követendő javaslat e tekintetben, olvastam már pro és kontra érveket (ember legyen a talpán, aki így dönteni tud, alaposabb ismeretek hiányában), illetve nvme SSD-k esetén kimondottan nem tartják szükségesnek (https://linuxmint.hu/comment/45560#comment-45560: a másik gépemben – Lenovo ts150 – ezt a lehetőséget választottam).

Ami a fájlrendszereket illeti Ext4, SWAP, és FAT32 van használatban:

norbi@ALBACOMP:~

$ findmnt

TARGET SOURCE FSTYPE OPTIONS

/ /dev/sda3 ext4 rw,noatime,discard

├─/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime

│ ├─/sys/kernel/security securityfs securit rw,relatime

│ ├─/sys/fs/pstore pstore pstore rw,relatime

│ └─/sys/kernel/config none configf rw,relatime

├─/proc proc proc rw,nosuid,nodev,noexec,relatime

├─/dev udev devtmpf rw,nosuid,relatime,size=1974208k,nr_

│ ├─/dev/pts devpts devpts rw,nosuid,noexec,relatime,gid=5,mode

│ └─/dev/shm tmpfs tmpfs rw,nosuid,nodev,noexec,relatime,size

├─/run tmpfs tmpfs rw,nosuid,nodev,noexec,relatime,size

│ ├─/run/lock tmpfs tmpfs rw,nosuid,nodev,noexec,relatime,size

│ └─/run/rpc_pipefs rpc_pipefs rpc_pip rw,relatime

├─/boot/efi /dev/sda1 vfat rw,relatime,fmask=0113,dmask=0002,al

└─/mnt/SHARED_DATA /dev/sda5 ext4 rw,noatime

norbi@ALBACOMP:~

Ha tényleg ennyire negatívan hat a heti TRIM az SSD életkilátásaira (https://thelinuxcode.com/fstrim-linux-command/(külső hivatkozás) : Automating fstrim for Hands-Free Operation rész: azt olvastam, hogy ezzel érdemes kezdeni és a szükségletek függvényében módosítani, esetemben leginkább nyújtani a periódus hosszát), akkor érdemes lenne kilőnöm a discard-ot is, mert elvileg ez egyenlő a napi TRIM használattal, ha helytállóak az értesüléseim???

Ha jól raktam össze a kirakóst, akkor a cron démon használatával időzíthető antiX esetén is ( /etc tartalmának listázása: https://paste.ubuntu.com/p/wRRjGSPmBn/(külső hivatkozás)), mivel létezik többféle is a gépen (https://ibb.co/dw4WK6Pp(külső hivatkozás)), igazából csak annyit kellene változtatni a korábbi elképzelésemen, hogy nem hetente, hanem évente fusson (ez a legnagyobb létező időköz, mely a javaslatodhoz /5-10 év/ legközelebb áll).

Egyébként azt hogyan tudom tesztelni, hogy az SSD lassulása elérte-e már a kritikus szintet („az SSD sebessége belassul 300 Gbps alá”), létezik erre egy bevált terminál parancs?

Manuálisan a TRIM-et gondolom a fenti (https://linuxmint.hu/comment/68899#comment-68899) bejegyzésemben emlegetett cron.weekly script tartalmát képező sudo fstrim -v –all... parancs futtatásával tudom véghez vinni (érdemes volna ezt futtatnom ebben a formában, hogy teszteljem, egyáltalán működik-e), az –all kapcsoló használható, vagy cseréljem le (, ahogy fentebb említettem), illetve ne módosítsak rajta úgy, hogy látható legyen az, amit csinált (...>> /var/log/trim.log)???

Nem automatizálható az egész úgy, hogy a TRIM-et nem időponthoz, hanem az SSD teljesítményéhez kötjük (ez lenne a legoptimálisabb), mondjuk egy olyan scrip írásával, ami időnként (naponta: cron.daily, vagy hetente: cron.weekly felhasználási szokásokra való tekintettel) automatikusan lefuttat egy parancsot, mely teszteli az SSD teljesítményét (optimális esetben partíciónként) és ennek az eredményét, akár naplózhatja is (a >> /var/log/trim.log-hoz hasonlóan), majd lefuttatja a sudo fstrim -v …. parancsot (, ha lehet, akkor csak a megfelelő partícióra), ha a meghatározott paraméterek adottak („az SSD sebessége belassul 300 Gbps alá”)???

#13  OK, tehát C2D proci, pcie 1.1, és SATAII interfész, 4 GB memória (ez a max támogatott).

Nem hiszem, hogy a SATAII interfész miatt nagy értelme lenne a TRIM-nek, elég hosszú ideig tartana amíg ebből (ennek hiányából) fakadó lassulást éreznél. Mármint az interfésznél amúgy 2X gyorsabb az SSD minimum, a működésben jelentkező lassulást addig nem is éreznéd, amíg fele alá nem csökken. A másik dolog az Ext4 fájlrendszer, ennek működéséből kifolyólag eleve nagyon ritkán van szükség TRIM-re. egy FATx/NTFS-hez képest, (nem gondolom, hogy btrfs-el telepítettél).

Normál esetben is a heti TRIM szerintem elég meredek dolog, bőven elegendő 1-2 havi, de még az is sok az Ext4 fájlrendszeren. Igaz, hogy megelőzi a belassulást, de ugyanakkor csökkenti az SSD élettartamát. Pont emiatt azt gondolom, hogy TRIM-et futtatni elég lehet akkor, ha majd lassulás érezhető.

Igen, systemd hiánya miatt nehézkes az időzítés. de nem tudom, hogy Antix alatt milyen eszközök vannak, ha meg valami külső időzítő démont kell telepíteni, azt gondolom fel kell azt venni az init-be, úgy képzelem. Mondom, nem ismerem....

De szerintem, pláne ha tartalék gép. akkor várd meg míg az SSD sebessége belassul 300 Gbps alá, és majd akkor futtass manuálisan TRIM-et, mondjuk úgy 5-10 év múlva talán.

u.i. TRIM futtatásához lehet szükséges az interfész támogatás is, de ebben nem vagyok biztos. AZ tuti, hogy a TRIM támogatás a későbbi SATAIII vezérlőkbe került bele, de ettől még a rendszer kezelheti ettől függetlenül is.

#19

Szívesen! Ahogy írtam, nem 100%, hogy igazam van, de szerintem nagyon nem nyúlhatsz mellé az ext4 használatával.

#18 Értem. Köszi szépen a tájékoztatást. Akkor maradok a bevált Ext4- nél.

#24

Szia!

Köszi a választ!

Akkor discard+nvme SSD, SATA+TRIM a két páros, mely nem keverendő, ilyen jellegű infóim eddig nem voltak. Ennek fényében még érdekesebb, hogy nálam mégis keveredik („Nem tudom, hogy mit csinál nálad a discard a SATA SSD-n…”), hogy miért, azt ne kérdezd, mert nem tudom megválaszolni.

Megnéztem a Lemezek teljesítménytesztjét, le is futtattam (az olvasásit, az írásit nem mertem: „...Mentse fontos adatait az írási teljesítményteszt megkezdése előtt.”):

SAMSUNG nvmeSSD+PCIe adapter átlagos olvasási sebesség: 2,7 GB/s (100 minta)

KINGSTON SATA SSD átlagos olvasási sebesség: 283,4 MB/s (100 minta), ez elég jónak tűnik („...3 Gbps a SATA II max sávszéllessége, ami durván 300 MB/s…”).

A hdparm futtatásának van valamilyen kockázata (a Lemezek teljesítménytesztjéhez hasonlóan), illetve melyik opcióval érdemes futtatni (telepítettem terminálban és a sudo hdparm futtatását követően dobott egy csinos listát a választékról), hogy ne barmoljak szét semmit (adatvesztés)?

#22 discard oda itt hetente továbbra is lefut a TRIM

A discard az nvmne SDD-hez való, mivel az nem ATA protokoll szerint működik. TRIM meg ATAIII+ protokoll parancs.

Ugyanazt a célt szolgálja min a kettő, de eltérő hardverhez való. Nem tudom, hogy mit csinál nálad a discard a SATA SSD-n...

Egyébként azt hogyan tudom tesztelni, hogy az SSD lassulása elérte-e már a kritikus szintet („az SSD sebessége belassul 300 Gbps alá”), létezik erre egy bevált terminál parancs?

Azt úgy tudod tesztelni, hogy leülsz elé, oszt tapasztalod, hogy belassult a rendszer. Mint alatt a  Lemezek alkalmazásnak van grafikus teljesítménytesztje, de terminálba ott a hdparm, vagy a fio (ezt jellemzően külön telepíteni kell, nem tartalmazzák alapból a disztrók)

 

#26

Köszönöm a helyesbítést és a kiegészítést.

#24 Már megfogadtam, nem fogok fáradtam mobilról írni..

nem 300 Gbps, amit folyamatosan írtam, hanem 3 Gbps a SATA II max sávszéllessége, ami durván 300 MB/s, de ebben benne vannak a CRC32 kódok, és csomagadatok is a hasznos bájtokon felül, ezt így kell érteni.

#22

Sparky esetén a (norbi@ALBACOMP:~$ ) systemctl cat fstrim.timer kimenete átvert, az igaz, hogy jelen volt/van ez az időzítés (gyárilag heti gyakorisággal), viszont, amikor kiadtam a systemctl status fstrim.timer parancsot, akkor szembesültem vele, hogy a gyakorlatban nincs aktiválva (disabled, inactive(dead)), így nem fut le. Nem tudom, hogy más járt-e hozzám hasonlóan, de javaslom, hogy az fstrim automatikus lefutásának ellenőrzésére inkább az utóbbi (systemctl status fstrim.timer), esetleg a systemctl list-timers --all parancsot használja az, akinek szüksége van ilyen jellegű infókra.

A heti (weekly) trim helyett havi (monthly) trim futtatást állítottam be (hasonlóan oldható meg az éves /yearly/ is, de mivel heti/havi futtatást javasoltak, így én a hetit választottam egyelőre: https://unix.stackexchange.com/questions/218076/ssd-how-often-should-i-do-fstrim(külső hivatkozás))

„...For 2), using fstrim weekly or even monthly is completely fine. There is no need to use instant discard, or to trim daily - that would be a short-term measure, but this is about keeping the SSD happy in the long-term. But it also depends on your usage: if your filesystem is always full and sees lots of writes, you might need to trim more regularly than if you tend to have lots of free space and not that much writes in your filesystems….”

„Running fstrim frequently, or even using mount -o discard, might negatively affect the lifetime of poor-quality SSD devices. For most desktop and server systems the sufficient trimming frequency is once a week.”

https://magyarlinux.hu/ssd-karbantartasa-fstrim-programmal/(külső hivatkozás):

Tehát akkor így módosítottam az fstrim-et (SPARKY esetén):

https://paste.ubuntu.com/p/GVXQNv6qHx/(külső hivatkozás)

Eközben felmerült bennem néhány kérdés/gondolat:

Elviekben az sda2 SWAP partíciót is kellene trimmelni erre viszont nem találtam megoldást (elvileg a swap fájl sem viselkedik másként). Azt írják, hogy csak a (fstab) discard az opció, ha jól értelmezem, ezt viszont szeretném elkerülni (ha jól sejtem, a trim manuális futtatásával is lehetne operálni, de ebben nem vagyok biztos, inkább automatizálnám):

https://bbs.archlinux.org/viewtopic.php?id=284561(külső hivatkozás) https://man.archlinux.org/man/swapon.8.en(külső hivatkozás)

„...-d, --discard[=policy]

Enable swap discards, if the swap backing device supports the discard or trim operation. This may improve performance on some Solid State Devices, but often it does not. The option allows one to select between two available swap discard policies:

--discard=once

to perform a single-time discard operation for the whole swap area at swapon; or

--discard=pages

to asynchronously discard freed swap pages before they are available for reuse.

If no policy is selected, the default behavior is to enable both discard types. The /etc/fstab mount options discard, discard=once, or discard=pages may also be used to enable discard flags...”

Ha minden igaz az sda1 BOOT partíciót sem ártana trimmelni (Az ANTIX tudja, a SPARKY nem, ahogy alább látszik):

„...The SSD itself does support trimming, and is being trimmed on root and boot partitions weekly…”

Ha ANTIX alatt adom ki a sudo /usr/sbin/fstrim --fstab --verbose --dry-run parancsot, akkor ezt kapom:

norbi@ALBACOMP:~

$ sudo /usr/sbin/fstrim --fstab --verbose --dry-run

[sudo] norbi jelszava:

/mnt/SHARED_DATA: 0 B (dry run) trimmed on /dev/sda5

/boot/efi: 0 B (dry run) trimmed on /dev/sda1

/: 0 B (dry run) trimmed on /dev/sda3

norbi@ALBACOMP:~

SPARKY alatt ezt a képet mutatja:

norbi@ALBACOMP:~$ sudo /usr/sbin/fstrim --fstab --verbose --dry-run

/mnt/SHARED DATA: 0 B (dry run) trimmed on /dev/sda5

/: 0 B (dry run) trimmed on /dev/sda4

norbi@ALBACOMP:~$

A tesztparancs azt mutatja, hogy a trim lefutna az ANTIX esetében is (örömteli hír, bár számítottam rá /korábban megtaláltam már a fájlt a rendszeren/), így most már biztos, hogy systemd hiányában ugyan kicsit macerásabban, de egy cron job létrehozásával időzíthető itt is.

A kimenetekből az látszik, hogy:

ANTIX esetén az sda1 /boot/efi partíción, az sda3 / partíción és az sda5 /mnt/SHARED_DATA-n;

SPARKY esetében pedig az sda4 / és az sda5 /mnt/SHARED_DATA-n futna le a trimmelés.

Tehát az ANTIX-nál az sda1 is trimmelve lenne SPARKY-nál azonban nem, viszont a SWAP (sda2) itt sem szerepel a listán.

A partíciós tábla így néz ki (ANTIX alól futtatva):

norbi@ALBACOMP:~

$ sudo parted /dev/sda p

Típus: ATA KINGSTON SKC6002 (scsi)

/dev/sda lemez: 256GB

Szektorméret (logikai/fizikai): 512B/4096B

Partíciós tábla: gpt

Lemezjelzők:

Szám Kezdet Vég Méret Fájlrendszer Név Jelzők

1 1049kB 2149MB 2147MB fat32 BOOT boot, esp

2 2149MB 6443MB 4295MB linux-swap(v1) SWAP swap

3 6443MB 60,1GB 53,7GB ext4 SYS1 legacy_boot

4 60,1GB 114GB 53,7GB ext4 root

5 114GB 256GB 142GB ext4 SHARED DATA

norbi@ALBACOMP:~

SPARKY esetén is lényegében ugyanez a kép:

norbi@ALBACOMP:~$ sudo parted /dev/sda p

[sudo] norbi jelszava:

Model: ATA KINGSTON SKC6002 (scsi)

Disk /dev/sda: 256GB

Sector size (logical/physical): 512B/4096B

Partition Table: gpt

Disk Flags:

 

Number Start End Size File system Name Flags

1 1049kB 2149MB 2147MB fat32 BOOT boot, esp

2 2149MB 6443MB 4295MB linux-swap(v1) SWAP swap

3 6443MB 60,1GB 53,7GB ext4 SYS1 legacy_boot

4 60,1GB 114GB 53,7GB ext4 root

5 114GB 256GB 142GB ext4 SHARED DATA

norbi@ALBACOMP:~$

GPARTED Antix alatt: https://ibb.co/Q3Xw6jrb(külső hivatkozás)

GPARTED Sparky alatt: https://ibb.co/nqxkqBpL(külső hivatkozás) elég hasonló az Antix esetében látottakhoz, de itt a /dev/sda1 Boot partíciónál egy felkiáltójel látható, ez nem tudom, hogy mire utal?

Egyébként az SDA5-öt nem kellene kilőni valamelyik rendszer esetén a trimből, mivel jelen pillanatban mindkettő képes lenne futtatni rajta, tehát duplán futna le, ha nem tévedek, ami felesleges (talán még káros is)?

Az nem opció, dualboot esetén, hogy az egyik rendszeren futtatom csak az időzített trimet, de úgy, hogy az összes létező (mindkét rendszerhez tartozó) trimmelendő partíción lefusson (nem csak a hozzá tartozó fstab-ban találhatókon, hanem valahogy rávenni arra, hogy más listából dolgozzon pl. UUID azonosítók alapján, vagy a pratíciók egyéb, pontos megjelölésével pl.: /dev/sda1, /dev/sda2,…)?

#20

A Sparky (ez a másik rendszer a gépen) fstabjában is elkövettem a discardtalanítást:

  GNU nano 7.2                                                     /etc/fstab                                                              
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
#EREDETI BEÁLLÍTÁS: AKTÍV DISCARD=NAPI TRIM: UUID=bcad14ee-8a35-41d2-9604-ea12896b7265 /              ext4    defaults,noatime,discard 0 1
UUID=bcad14ee-8a35-41d2-9604-ea12896b7265 /              ext4    defaults,noatime 0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
LABEL=SHARED\040DATA /mnt/SHARED\040DATA auto defaults,noatime,x-gvfs-show 0 0

Itt a partíciók meglehetősen eltérő képet mutatnak, hálás lennék, ha ezt értékelné valaki.

Végül lefuttattam a systemctl cat fstrim.timer parancsot (mivel az antiX-val ellentétben a Sparky nem systemd free, így ismeri):

norbi@ALBACOMP:~$ systemctl cat fstrim.timer
# /lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim
ConditionVirtualization=!container
ConditionPathExists=!/etc/initrd-release

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true
RandomizedDelaySec=6000

[Install]
WantedBy=timers.target
norbi@ALBACOMP:~$

Úgy tűnik, hogy discard ide, discard oda itt hetente továbbra is lefut a TRIM, a szép az egészben az, hogy futtattam a Lenovon is (itt nem maceráltam MInt telepítéskor és elvileg az mnve SSD miatt nem is kell) és ha jól látom ott is lefut hetente:

norbi@LENOVO-TS150:~$ systemctl cat fstrim.timer

# /usr/lib/systemd/system/fstrim.timer

[Unit]

Description=Discard unused filesystem blocks once a week

Documentation=man:fstrim

ConditionVirtualization=!container

ConditionPathExists=!/etc/initrd-release

 

[Timer]

OnCalendar=weekly

AccuracySec=1h

Persistent=true

RandomizedDelaySec=100min

 

[Install]

WantedBy=timers.target

norbi@LENOVO-TS150:~$