Debian 9 telepítése SSD-re hogyan? Telepítés, beállítási tanácsokat kérek.

Debian GNU/Linux

Sziasztok!

A témát még a 'Merevlemezek, vezérlők' fórumtémához tudtam volna sorolni, de nem akartam duplán beküldeni.

Dell Optiplex 780 SFF
Intel Core2Duo processzor; 2GB RAM; Kingston UV400 120GB SSD (NAND: TLC)

A fenti konfigurációra szeretnék Debian 9-et telepíteni Cinnamon felülettel. Linuxszal kapcsolatos oldalt találtam sokat, de mindenhol mást írtak, így hát összeállítottam egy "saját" leírást. Az interneten elérhető anyagok után van elképzelésem, hogy csinálnám meg a telepítést és beállítást. Amiben nem vagyok biztos, hogy a RAM elegendő lesz ehhez, vagy másként kellene megoldanom. Az SSD használatot illetően is két ellentétes vélemény körvonalazódott ki. Egyik, hogy csak rendszer legyen az SSD-n, ne legyen swap (vagy HDD-n), az adatok HDD-n legyenek. A másik szemlélet szerint egy SSD-t lehet úgy használni, mint egy hagyományos háttértárat - minden mehet rá, még a swap is.
A számítógép leginkább csak internetezésre van használva. Hibernálás nincs használva, naplófájlokat nem nézegetnek a gépen.
Amennyire leszűrtem SSD-nél GPT partíciós táblát kell használni. A számítógépen nincs EFI/UEFI, hagyományos BIOS-os alaplapja van még.
Jelenleg Debian 8 fut rajta Cinnamon felülettel, HDD-n. A normál használat mellett eddig nem nagyon ment 1-1,2GB fölé a RAM fogyasztás, swap 0MB használattal megy.

Az elképzelés:
- Partíciók: 500MB /boot; 20GB a /-nek, 4GB swap, maradék a /home-nak. Az SSD végén nem hagynék formázatlan szabad helyet.
- Fájlrendszer: ext4
- fstab opciók: discard és noatime minden partícióra a swap kivételével.
- TRIM futtatása heti rendszerességgel: /etc/cron.weekly/fstrim fájlban 'set -e és exec fstrim-all', vagy 'exec fstrim-all --no-model-check'
- Ideiglenes fájlokat a RAM-ban tárolni, fstab szerkesztésével
tmpfs /tmp tmpfs defaults,noatime,size=5%,mode=1777 0 0
tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0
tmpfs /var/spool tmpfs defaults,noatime,size=1%,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,size=1%,mode=1777 0 0
- Firefox böngésző gyorsítása:
Override automatic cache management = 0 MB
browser.sessionstore.interval = 15000000
browser.sessionstore.restore_on_demand
browser.sessionstore.resume_from_crash
services.sync.prefs.sync.browser.sessionstore.restore_on_demand
- /etc/sysctl.conf fájlban hozzáadni 'vm.swappiness=1' (ha van swap)
- Ha nincs swap partíció akkor a RAM-ba tenni: /etc/fstab szerkesztése
mkswap /dev/ram0
swapoff -a
swapon /dev/ram0

Kérdések:
Az SSD végén kell üres, formázatlan helyet hagyni? Ha igen mennyit(GB vagy %)?
A discard opció az fstab fájlban szükséges még? Valahol olvastam, hogy ma már nincs hatása az SSD-nél.
Elég a heti TRIM?
A /tmp és /var RAM-ban tárolása esetén elég lehet a 2GB RAM? Ha nem mennyi kellene minimum? A százalékos megadással elérhetem azt, hogy ne fagyjon ki a gép?
A mai SSD-knél lehet swap partíciót használni? Befolyásolja ez az élettartamot még?
Ha van swap, akkor a swappiness=1 beállítás minimalizálja a swap használatot? Csak akkor lesz használva, ha már nagyon kell?

Mivel az SSD témakör új számomra, ezért kérnék gyakorlati tapasztalatokat, javaslatokat. Jó az elképzelés, vagy valamit inkább máshogy, vagy egyáltalán ne csináljak?
A cél az lenne, hogy a gépben csak 1db SSD legyen és egy optimális teljesítmény/élettartam arányt el lehessen érni. Fontos lenne, hogy a /tmp és /var RAM-ba íratása esetén ne fagyjon ki a gép még véletlenül sem, mert nem áll módomban bármikor helyszínre menni a távolság miatt.

  • 4956 megtekintés

( zitev v | 2017. 05. 30., k – 09:31 )

sub

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( uid_20269 | 2017. 05. 30., k – 09:36 )

Szerintem fölösleges a swap, ha biztosan nem akarsz hibernálást. Illetve előbb áll meg a tápod vagy adja meg magát valamelyik kondi ebben a gépben, mint hogy az SSD meghalna..
--
God bless you, Captain Hindsight..

( bennyh | 2017. 05. 30., k – 09:39 )

Szerintem, ha fut a trim és hagysz vagy 15-20% szabad helyet (nem a végén partíció nélkül hanem úgy összességében a köteteken, pl kvóta segítségével, és a trim által úgy is megtalálja a vezérlő a szabad helyet), akkor ma már nagy baj nem lehet.

( raziiii v | 2017. 05. 30., k – 09:43 )

Én nem foglalkoztam azzal, hogy miként formázzam le :D Ment úgy ahogy alapból a linux( vagy a win) akarta
Sosem hagytam helyet az SSD-k végén, nem adódott ebből még probléma.

Megpróbálkoztam a beállításával Debian Wiki alapján.
Az utolsó lépésnél elakadtam.
A 'sudo insserv zram' prancsra azt a választ kapom, hogy a 'sudo: insserv: parancs nem található'.
Tudnál segíteni, hogyan lehetne ezt a ZRAM-ot működésre bírni már a gépinduláskor?

A 'sudo /etc/init.d/zram start' manuális indítása után (ami 4db 1,5GB-os helyet hoz létre), a 'lsmod | grep zram' parancsot lefuttatva a következőt kapom:
$ lsmod | grep zram
zram 24576 4
zsmalloc 24576 1 zram

Szia!

Nalm ennyi van /etc/rc.local-ban (hogy mindennek a vegen fusson le).


modprobe zram
echo $((1024*1024*1024)) > /sys/block/zram0/disksize
mkswap /dev/zram0
swapon -p 10000 /dev/zram0

Ez mondjuk 1G meretut hoz letre, masodik sorban. Priot meg jo magasra raktam, ha az ssd-n levo swap oarticiot
be akarom kapcsolni, akkor is csak akkor irjon oda, ha hibernalni akarom

16G rammal 80M swapot fogyaszt, de azt stabilan :)

--
http://www.micros~1
Rekurzió: lásd rekurzió.

( Mik v | 2017. 05. 30., k – 10:15 )

Szia,

Total Bytes Written (TBW) 120GB: 50TB
Azaz ha minden nap koppra teleírod akkor is több mint 400 napot ki kell bírnia. Ez egy internetezésre használt gépnél nem túl életszerű, ezért szerintem az összes varázslás amit leírtál felesleges. Ha csak 12GB-ot írsz rá egy nap, akkor már 10 év feletti élettartamról beszélünk...

Nagyobb környezetben az egyik leglényegesebb szempont, hogy mennyit lehet rá írni? Az általad leírt megoldásokkal lehet kicsit finomhangolni, de komoly rendszerek -pl. adatbázisok- alatt ezekkel csak kevés időt lehet nyerni. Szerencséd, hogy olyan SSD-t vettél aminek rendes adatlapja van és meg van adva ez az érték. Még egyszer: én nem aggódnám túl a dolgot az esetedben.

( zslaszlo v | 2017. 05. 30., k – 10:26 )

Én most raktam ssd-re linuxot, de nem is volt kérdéses,hogy lvm partíciók lesznek. Miért nem használsz lvm-et?

LVM témában mostanában kezdtem az informális ismerkedést. Ami miatt tartok tőle (az ismeretlentől), hogy rendszer összeomlás esetén hogyan tudnék adatokat menteni. Egy sima ext4-ről bármivel le tudom menteni az adatokat, de LVM-mel még nincs tapasztalatom. Debian LIVE-ról gondolnám megoldható, de nem tudom az 'LVM-kezelő' csomag rajta van-e. Például nekem Gparted hiányzik róla. :)

Az lvm, nem más,mint logikai kötetkezelő. Tehát nem a hagyományos primary secondary particiós táblákkal dolgozol. Érdemes megismerkedni a vele (nem ördöngös dolog), ha jól rémlik az arch honlapján tök jó magyar nyelvű leírás is van, ha pedig angolul is tudsz,akkor tele a net infóval. Ha később particiókat szeretnél átméretezni,módosítani, összevonni, szétszedni,stb nagyon nagy segítség. Jópár fájlrendszer még az on the fly módosításokat is támogatja.
Szerk.: Ja igen, és az lvm2 csomag alap része a Debian telepítőnek.

az lvm2 csomag alap része a Debian telepítőnek

Debian 9.0.1 live+nonfree és 9.1 live+nonfree-n próbáltam, ott valamiért már nem volt benne, persze egy apt-get install és fent is van.... Én is furcsálltam, de azért jó tudni!
Egyébként +1 az LVM-re. Pár parancsot tudni kell de ha az megvan akkor jó dolog ám!

--
Debian 8.8 Jessie, Android 6.0.1 Marshmallow, OpenWrt 15.05.1 Chaos Calmer, Armbian 5.24, Free MC Boot 1.953+OPL 0.9.78-DB, Boyue C60 20140410 (Gentoo)

( bartaszili | 2017. 05. 30., k – 12:28 )

https://sites.google.com/site/easylinuxtipsproject/ssd
---
Érdemes elolvasni. Nem kell túlvariálni. Lényeg, max 10GB szabad helyet hagyj akárhol - pl Crucial SSDknél nem szükséges, mert te nem látod, de gyárilag hagytak üres helyet, vagy Intel P600 szintén ilyen.
Az egyes partíciókon legyen bő 20% üresen ezzel minimalizálod a fragmentációt.
A trimmelést pakold át napi feladatnak.
Noatime, nodiratime az fstabba és csók. Swapet dobd a sima hdd-re, nem baj ha van, úgyse piszkálja. Vegyél pluszba ramot.

A hivatkozott oldalt olvastam már. A noatime nem "erősebb" a nodiratime-nál? Előbbi fájlokra és könyvtárakra, utóbbi csak könyvtárakra vonatkozik - ha jól emlékszem. Azt olvastam, hogy emiatt elég a noatime.
RAM-ot ehhez már nehéz, vagy drágán lehet venni. Sajnos a RAM pontos típusát nem tudom. Beépítéssel próbáltam nagyobb (2GB, 4GB) RAM-ot, de nem indult el a gép.

Asztali gépnél még csak-csak oké lehet egy plusz HDD, de laptopnál nehezen kivitelezhető, ahol mondjuk csak egy beépítő hely van. A topik indítóban asztali gép szerepel, de lehet jól jönne másnak laptop esetére egy jó megoldás, ahol mondjuk a RAM sem nagyon bővíthető már. Ott mi a teendő?

Egy minimális SWAP 2GB elfér az SSDn. Ha van elég RAM, akkor szinte érintetlen marad. Cool swap nélkül üzemeltetni az otthoni gépedet, de stabilitás szempontjából van ami megkívánja a swap meglétét. HP DC6200 desktop 4GB RAM-mal. 120 GB SK-Hynix SL308 SSD-vel. Meg a tartozék HDD. Azon van a SWAP. Már egy pár hónapja hogy telepítettem, de azóta se használta. A swappiness-t se piszkáltam.

( kleinie | 2017. 05. 30., k – 15:33 )

A mai SSD meghajtókkal már tök felesleges ez a mókuskodás, nem fogsz annyi forgalmat csinálni, hogy azzal nyírd ki. Az SSD-hez nem kell GPT. A szétdarabolás sem feltétlen kell, legyen külön a rendszer és a home, esetleg a boot (ha nem akarsz több rendszert, akkor azt is felesleges külön rakni), a swap-ot én swap fájlnak csinálnám meg.

"Az SSD-hez nem kell GPT."
Igaz, az UEFI-s telepítést kevertem ide. Egy másik gépnél meg ez 'kell' majd. Általában /; /home; swap partíciókat szoktam létrehozni. Szeretem, ha az adatok külön vannak a rendszertől. Ezt anno még Windows-on is így csináltam a kezdetek óta.
SWAP fájlt hogyan kell létrehozni partíció helyett?

( xclusiv v | 2017. 05. 30., k – 20:00 )

Címszavakban:

"2GB RAM"
Javaslom tegyél mellé még kettőt. A 780-as azt hiszem 4 ram slot-os, 1-2 gigás modulokat használtan olcsón találsz szerintem.

"Egyik, hogy csak rendszer legyen az SSD-n, ne legyen swap (vagy HDD-n), az adatok HDD-n legyenek."
Minden legyen az SSD-n. (Na jó, a rendszeres mentés máshol, illetve komolyabb médiagyűjtemény is mehet pl. NAS-ra :)

"A számítógép leginkább csak internetezésre van használva."
ublock origin, különösen ha nem bővítesz memoárt.

"Amennyire leszűrtem SSD-nél GPT partíciós táblát kell használni."
Nem szükséges

"- Partíciók: 500MB /boot; 20GB a /-nek, 4GB swap, maradék a /home-nak. Az SSD végén nem hagynék formázatlan szabad helyet."
Kell a 20g /-nak? Illetve én nem biztos hogy külön /home partíciót csinálnék, de ez vallási kérdés.

"- fstab opciók: discard és noatime minden partícióra a swap kivételével.
- TRIM futtatása heti rendszerességgel: /etc/cron.weekly/fstrim fájlban 'set -e és exec fstrim-all', vagy 'exec fstrim-all --no-model-check'"
nem kell a discard, elég időnként a trim. Én pl. rc.local-ba raktam.

"- Ideiglenes fájlokat a RAM-ban tárolni, fstab szerkesztésével"
Lehet, de nem szükséges. Ártani nem ártasz vele.

"- Ha nincs swap partíció akkor a RAM-ba tenni: /etc/fstab szerkesztése"
Nem, ha nincs swap partíció akkor vagy swapfile legyen, vegy ne legyen swap. És nem is nagyon van /dev/ram0, azt csinálni kell szerintem. És amúgy is baromság, hogy a memória egy részét lefoglalom arra, hogy ha kifogy a memória akkor oda az OS "kilapozza a memóriából" azt, ami pillanatnyilag nem kell.

"Az SSD végén kell üres, formázatlan helyet hagyni? Ha igen mennyit(GB vagy %)?"
Én nem hagyok formázatlan helyet, de üres hely van a partíciókon. Az SSD vezérlő számára nincs olyan hogy formázott vagy nem formázott terület, neki csak használt vagy üres blokkok vannak. Azt pedig megmondja neki a trim, hogy az adott blokk kiürült.

SSD para: nem kell aggódni, de mentés legyen. Az SSD _elvileg_ úgy hal el, hogy a cellák a sok írástól nem lesznek írhatóak, tehát az adataid megmaradnak readonly. Gyakorlatilag annyit úgyse fogsz rá írni amitől meghalna, szóval ha meghal akkor a vezérlő adja be a kulcsot és buksz minden adatot.
Én többször is írogattam már itt az én SSD használatomról, ha érdekel keress utána (google://site:hup.hu xclusiv ssd written).

"A /tmp és /var RAM-ban tárolása esetén elég lehet a 2GB RAM?"
Felejtsd el ezt! Az SSD full kommersz eszköz, nem igényel különösebb odafigyelést. Évek óta használja a fél világ "os default" beállításokkal, és mégis 1-2 "szarvezérlős" széria kivételével nincs rájuk panasz.

Ami fontos: bios-ban ahci, nélküle nem megy a trim ha jól tudom.
Scheduler pedig legyen noop, bár igazából olyan mindegy ez is.

Majdnem mindennel egyetértek. Főleg azzal, hogy nem kell kímélni az SSD-ket. Ez még egy régről gyökerező tévhit, mikor újak voltak az SSD-k, senki nem tudta mit bírnak, és félelemből, bizalmatlanságból mindenki túlkímélte. Azóta bebizonyosodott, hogy többet bírnak, mint azt elsőre gondolták, felesleges túlkímélni. Plusz ennyi erővel ha semmi nincs az SSD-n, akkor minek SSD, be lehet rakni egy üvegvitrinbe, és ott nézegetni, úgy nem használódik el. Azért veszik őket, hogy használva legyenek, és gyors legyen a rendszer. Szerintem is swapfájl legyen, annak a mérete később rugalmasan átszabható, és maradjon az SSD-n. Esetleg ha annyira csak a szükséges mértékre akarjuk szorítani a swapot, akkor a vm.swappiness-t le lehet venni alacsony értékre, a topiknyitóban írt 1-es érték megfelelő lehet erre.

Két pont van, amivel nem értek egyet. Az egyik, hogy kellhet a GPT-s particióstábla, ha UEFI-s bootot akar az ember. Nem amiatt kell az GPT, mert SSD-ről van szó, hanem az UEFI-nek. Ha viszont nem kell UEFI-s boot, akkor MBR-rel is jó. A másik, hogy a TRIM elvileg megy AHCI nélkül is, de tényleg javasolt bekapcsolni mindenképp.

A partícióalignálást érdemes lehet még ellenőrizni, de a mai modern particionálóprogramok már nem szokták elszúrni, a Debian telepítője is jól kezeli. A másik kérdés még, ami nem került szóba, az a fájlrendszer. Nyugodtan mehet rá ext4, vagy akár btrfs is, egyéni ízléstől, megszokástól függően. Az f2fs sem mellényúlás, eleve flash/NAND alapú meghajtókra tervezték, de a gyakorlat azt mutatja, hogy nem jobb, mint az ext4 és társai, és nem kíméli jobban a meghajtót.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

"Ez még egy régről gyökerező tévhit,..."
Mivel a neten régebbről is vannak írások, és vannak relatív frissek is, így egy kicsit ellentmondásosak az információk. Erre utaltam a topik indítóban. Mivel nem tudok heti szinten az adott gép közelében lenni, ezért szeretnék elsőre jó és megbízható megoldást alkalmazni.

"...ennyi erővel ha semmi nincs az SSD-n, akkor minek SSD,..."
Ezzel én is így vagyok. Mivel ismeretlen számomra az SSD gyakorlati használata, így megkérdeztelek benneteket. Alapvetően nem akarok második eszközt az adattárolásra, ha csak valami nem indokolja. Ez is egy tisztázandó kérdés volt részemről.

"Szerintem is swapfájl legyen, annak a mérete később rugalmasan átszabható, és maradjon az SSD-n."
Ehhez tudnál egy kis segítséget adni? Weboldal, angol, magyar, bármi jól jönne. Azért rákeresek én is. Eddig csak partíció formájában használtam SWAP-ot. Fájlként nem tudom hogyan kell létrehozni, használni.

GPT, UEFI, SSD, AHCI
Ezt kicsit összekevertem az elején, de mostmár tiszta.

Debian-t netinstall-ból (expert módban, nem azért mert szakértő lennék) telepítek mindig és telepítés közben partícionálok. Grafikus megoldásokból a Gparted-et szoktam meg és használom. Fájlrendszernek ext4-et fogok használni.

Swap file-t így csinálhatsz (rootként):

1) Csinálj egy jó nagy fájlt. Mondjuk így: 

fallocate -l 4G /swapfile

1.5) Érdemes a jogosultságokat így belőni: 

chmod 600 /swapfile

2) Ezt kell futtatnod, hogy swap file legyen belőle: 

mkswap /swapfile

3) fstab-ba mehet be: 

/swapfile    swap    swap    defaults    0 0

Remélem nem felejtettem ki semmit.

"A 780-as azt hiszem 4 ram slot-os..."
Igen, nekem is úgy rémlik. Azt hiszem neki futok még egyszer a +2GB RAM keresésnek.

"Minden legyen az SSD-n."
Abban a háztartásban, ahol a célgép van, nincs lehetőség szerver/nas használatára. A mentésekre kitalálok valamit, mostanra megtanultam, hogy amiből egy példány van, az nem fontos adat. :) Menteni, menteni.

"Kell a 20g /-nak? Illetve én nem biztos hogy külön /home partíciót csinálnék, de ez vallási kérdés."
Minden gépen ennyit adok, bár a tapasztalat az, hogy feleslegesen sok. 10GB fölé még soha egyik asztali géppel mentem /-partíción.

"És amúgy is baromság, hogy a memória egy részét lefoglalom arra, hogy ha kifogy a memória akkor oda az OS "kilapozza a memóriából" azt, ami pillanatnyilag nem kell."
Jobban átgondolva, teljesen jogos ez a vélemény.

"SSD para: nem kell aggódni, de mentés legyen."
A hozzászólásaitok után egyre nyugodtabb vagyok. Pár általam összegyűjtött megoldást át kell gondolni.

Köszönöm az észrevételeket!

( bartaszili | 2017. 05. 31., sze – 09:29 )

GPT vs MBR
Annyit tennék hozzá, hogy GPT rugalmasabban engedte a partíciók átvariálását, amikor épp erre volt szükség. Ellenben az MBR nem engedte hogy két partíció között létrehozzak egy harmadikat, vagy hogy az első partíciót lezsugorítottam, és a második elejét ki akartam terjeszteni az első végéig. Nem most volt, már homályos a dolog. Annyi biztosan rémlik hogy a GPT rugalmasabb ebben. Majd ha egyszer lesz időm nyomok egy egy memory refresht VBoxban...

( tothgab | 2017. 07. 14., p – 07:07 )

A topik indító és a hozzászólások segítségével összegyúrtam a rendszert, szépen és gyorsan működik. Köszönöm mindenkinek!
Ha lenne rá igény szívesen megírom a lépéseket blogban is, ahol összeszedettebben lenne meg. Természetesen ott is lehetnek még javítani valók. :)

Egy kérdésem marad hátra: fstrim.
1) Van aki szerint a /etc/rc.local fájlba kell betenni. Ennek eredménye, hogy minden gépinduláskor lefut az fstrim, ezzel kinyújtva a boot időt, akár percekkel is (nem próbáltam, nem tudok nyilatkozni).
2) Második javaslat a /etc/cron.daily/fstrim fájlba betenni a futási parancsot. Én egyelőre ezt választottam.
3) Napi trim helyett a hetit választani és /etc/cron.weekly/fstrim fájl használata.
4) Időnként kézzel lefuttatni, ha "lassul" a rendszer.
5) Betenni az "Automatikusan induló alkalmazások) közé. Ez szinte megegyezik az 1) megoldással, csak rendszer indulás után történne meg.
6) Valahogy megoldani, hogy kikapcsoláskor fusson le az fstrim.

Ha jól tudom, a cron.daily és cron.weekly alatt elhelyezett parancsok adott napon éjfélkor futnak le alapértelmezésben. Keresgélésem alapján azt is megtudtam, hogy lehet adott időpontot (óra:perc) beállítani a cron folyamatok futtatására.
Kérdés, hogy mi történik akkor, ha adott időpontban (akár éjfél, akár beállított időpont) a számítógép nincs bekapcsolva? Megtörténik az fstrim futtatása, amolyan pótlásként, vagy majd legközelebb az ütemezés szerint?

Mi lenne szerintetek az optimális megoldás és annak menete egy olyan gépnél, ami rendszertelen időpontokban van használva?

7. rc.local-ba az "exit 0" elé ezt írod:

(
/bin/sleep 600
/sbin/fstrim /
/sbin/fstrim /boot
/sbin/fstrim /whatever
)&

Így nem lassít semmit, mert subshell indul és a shell indítja a következő process-t. Ráadásul vár 10 percet mielőtt nekiáll trim-melni, ennyi idő alatt valszeg elindítasz mindent amit el akarsz indítani, amikor pedig indul a trim akkor valszeg minimális terhelést kap az SSD.

Percekig pedig csak nem fut már, reálisan 2-3 másodperc.

Nem jelent élettartamcsökkenést a túl gyakori TRIM, hiába terjesztik az ellenkezőjét a neten. Az oka az, hogy az fstrim csak a trimmeletlen adatokat trimmeli, ezt úgy tudod ellenőrizni, hogy kézzel terminálban többször lefuttatod a sudo fstrim -a -v /dev/sdX parancsot, először több másodperc, mire régóta trimmeletlen meghajtón lefut, aztán már csak max. 1 mp, majd 0 mp, és ki is írja, hogy „0 B (0 bytes) trimmed”. Érdemes fstrimnél az -a kapcsolód használni, és akkor nem kell neki külön megadni az összes csatolási pontot. Én kézzel futtatom le kb. hetente, ha nagyon sokat írok, törlök a meghajtón, akkor néha naponta.

Ugyanez igaz a discard mountos TRIM-re is (a windowsos TRIM is ennek felel meg), menet közben az is csak mindig az épp aktuálisan letörölt adatokat trimmeli, nem az egész meghajtót feleslegesen.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

( szabek | 2017. 07. 14., p – 09:12 )

Emiatt nem nyitnék új topicot, de mi a helyzet, ha 3 ssd-ből raid5-t csinálnék. Mennyire szereti ezt az ssd ill. mdadm?

Az SSD-knek kb. minden halál mindegy. Ezért a topikindító által bevetett kímélő intézkedések 99%-a felesleges, ugyanúgy lehet használni, mintha HDD lenne.

Felesleges noatime-mal mountolni, nem okoz sok írást. A discard maradhat, de akkor nem kell a cron fstab, feleslegessé válik. A kétféle TRIM-ből elég csak az egyiket használni, ha van cron fstab (elég a heti), akkor meg a discard opció nem kell. Persze mehetnek együtt is, nem zárják ki egymást, csak felesleges. Nem kell variálni a bőngészőcache-t és a tmpfst sem, maradhatnak az SSD-n.

2 giga RAM nem valami acélos, ahhoz kell swap, de nem kell swap partíció, elég swapfájl (kivéve Btrfs-en, mert az nem támogatja), és nyugodtan mehet az SSD-re. A Linux kevesebbet ír a meghajtóra amúgy is, mint a Windows, meg kevésbé agresszíven is swapol, nem kell tőle tartani, hogy elhasználódnak az SSD cellái, nem kell csökkenteni az írásokat.

SSD-re sem kötelező a GPT, ugyanúgy működik MBR-rel, persze én azért maradnék a GPT-nél, néhány lap UEFI/GPT-s boottal gyorsabban bootol, meg a GPT a jövő. Amúgy ugyanolyan gyors az SSD MBR-res partíciós táblával is.

A linuxos particionáló toolok eleve 4K-s határokon alignálják a partíciókat, meg egyre több modern SSD-nek már nem is fontos az alignálás, mivel 512 bájtos logikai szektormérettel rendelkeznek, mint a hagyományos HDD-k. Emiatt nem kell aggódni.

Ugyanígy felesleges az SSD-n 10-20% formázatlan helyet hagyni, elég csak arra figyelni, hogy sose telítsük be csordultig, mert akkor az SSD vezérlőjének wear levelingje nem tud működni, de már a HDD-k sem szerették, ha csordultig vannak, mert akkor meredeken nőtt a töredezettség, szóval az SSD-k ebben sem különböznek annyira a HDD-ktől.

Ha egész lemezes szoftveres titkosítást használ az ember (pl. LUKS) vagy LVM-et, vagy mindkettőt egyszerre, akkor viszont figyelni kell, hogy a TRIM működjön, de erre vannak leírások az Arch Wikin vagy a Gentoo Wikin.

Illetve néhány vezérlőn problémás a discard TRIM, mivel firmwarehiba miatt nem hajtódik végre megfelelő sorkezeléssel, ezért a kernel ezeknél azonnal kikényszeríti a TRIM parancsot, ami pedig teljesítményproblémákhoz vezet. Ezeken az SSD-ken az fstrimet kell használni discard helyett, az mindegy, hogy cronban van az fstrim, vagy kézzel adjuk ki nagy ritkán a 

sudo fstrim -v -a

parancsot, én az utóbbit csinálom, igaz csak tesztképpen, tapasztalatgyűjtésnek, hogy mennyivel hatékonyabb, mint a discard TRIM. Ezekről a discard TRIM problémás SSD-kről, vezérlőkről a lista itt található (4520-as sortól).

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

( uid_16313 | 2017. 07. 25., k – 20:00 )

Régóta tervezem, hogy felrakom F2FS-re, de még sosem jutottam el odáig, hogy élesben kipróbáljam.

--
robyboy