Az sdb a HDD. Az sdb1 régen /boot
volt, most senki földje, 512 MB. Az sdb2 extended konténer. Az sdb5 egy 8.1 GB-os swap. Az sdb6 egy lvm pv, de egyben vg is. Rajta két lv, az egyik 241 GB /home
, a másik 216 GB /var
. Ez utóbbi két szegmensből, mert a régi rootfs-t is megkapta, s a filerendszer vége a HDD-n fizikailag előrébb van, mint az eleje. Az lvm szépségei, könnyen managelhető.
Az fstab-ban az SSD-n lévő sda3-at a /usr/local/share/mnt/varlib
alá csatoltam. Ide mozgattam a /var/lib/{dnf,rpm,yum}
könyvtárakat. Szintén az fstab-ban bind mount-oltam a /var/lib/{dnf,rpm,yum}
üres könyvtárakhoz az SSD-n lévő /usr/local/share/mnt/varlib/{dnf,rpm,yum}
könyvtárakat. Ezzel elértem, hogy noha a /var
HDD-n van, ez a néhány könyvtár mégis SSD-n, így a frissítés gyors lesz.
Írtam egy /etc/systemd/journald.conf.d/10-small_journald.conf
file-t az alábbi tartalommal:
[Journal]
SystemMaxUse=16M
SystemMaxFiles=64
RuntimeMaxUse=16M
RuntimeMaxFiles=32
Ezzel a logok kicsik lesznek, a korábban emlékeim szerint 12 másodpercig futó systemd-journal-flush.service
most 0.717 s alatt végez. Ugyanúgy HDD-re, csak kicsit kevesebbet. A konfig megírása után újra kell indítani a systemd-journald
szolgáltatást, és érdemes a journalctl --sync
, journalctl --flush
és journalctl --rotate
parancsok egyszeri használata, mert különben jó ideig marad még a nagy log file. A --vacuum-size=
paraméterrel hívás is hasznos lehet itt. Kell a fenének a sok szemét.
A plymouth-t eltávolítottam a dracut erase plymouth-\*
paranccsal. A grub.cfg
-ben a kernel paraméterek közül eltávolítottam az rhgb
paramétert. Használom a psd-t - profile-sync-daemon -, ezért írtam egy /etc/modules-load.d/psd.conf
file-t ezzel a tartalommal:
# Load overlay fs kernel module. Use it profile-sync-daemon.
overlay
Ezen felül egy /etc/dracut.conf.d/psd.conf
file-t, amelyben ez van:
filesystems+=" overlay "
Ezt követően generáltam egy új initrd-t:
dracut -f
Ezen felül a felhasználók ~/.mozilla
könyvtárait .mozilla.valaki néven SSD-re tettem. Most látom, hogy a rootfs-re, de átteszem majd a direkt ezért létrehozott sda3-ra. Ezekre symlinkek mutatnak a felhasználók $HOME alkönyvtáraiból. Itt fontos, hogy a .mozilla.valaki alkönyvtáraknak 0700-as jogaik legyenek, s az illető felhasználó legyen a tulajdonos.
Kezdetben 53 s körül volt a boot time SSD-ről, igaz, a /home, /var HDD-n. Néhány kivételtől eltekintve a /home, /var most is HDD-n van, így kímélem az SSD-t, ezzel szemben a boot time:
systemd-analyze
Startup finished in 2.036s (kernel) + 1.013s (initrd) + 10.578s (userspace) = 13.628s
Részlet az fstab-ból:
UUID=12345678-9abc-def0-1234-56789abcdef0 /usr/local/share/mnt/varlib ext4 noatime,discard 1 2
/usr/local/share/mnt/varlib/dnf /var/lib/dnf none bind 0 0
/usr/local/share/mnt/varlib/rpm /var/lib/rpm none bind 0 0
/usr/local/share/mnt/varlib/yum /var/lib/yum none bind 0 0
- locsemege blogja
- A hozzászóláshoz be kell jelentkezni
- 2405 megtekintés
Hozzászólások
Normál, hétköznapi használat mellett az SSD kb. 10x fogja túlélni a gépet, amiben használod. Szerintem felesleges ez a sok flikk-flakk megelőzni a "kifáradást". Nyilván filmeket, zenéket, képfájlokat tárolni jó a sima HDD is.
- A hozzászóláshoz be kell jelentkezni
Persze, hogy jó, csak már helyem nem volt. Azért az élettartamra ne végy mérget, mert nem vagyok a fogyasztói társadalom reguláris tagja. :) Értsd úgy, hogy a gépem 8 éves, és most raktam bele RAM-ot, SSD-t, tehát nem érzem úgy, hogy lejárt az ideje. A telefonom talán 10 év körül jár. A /var meg arra van, hogy ott gyakran íródjanak a dolgok, szóval amennyiben az élettartamot nem úgy értelmezzük, hogy 2 évente gépet cserélünk, úgy szerintem célszerű a /var nagy részét HDD-n tartani, csak néhány sebesség szempontjából kritikus dolgot érdemes visszabind-elni az SSD-re.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Először célszerű lenne mérned, mert nem kicsit becsülöd túl a /var és a /home írásának a mennyiségét.
Itt nem 2 év vs 8 év élettartamokról van szó, hanem kb. 80 év vs 300 év-ről.
Napi 100G írásnál bírná minimum 3 évig, szerintem egy normál felhasználó általában két nagyságrenddel kevesebbet ír egy nap, de eggyel biztosan.
Itt egy írás a témában, de van sok másik is.
- A hozzászóláshoz be kell jelentkezni
+1
Én egy 4 éves Dell laptopban használtam kb tavaly év végéig root partícióként a még régi 7-8 éves laptopomba vett ssd-t. Most HDD a root, ssd-t csak sshd féle cache-re használom.
Az ssd egy 60gigás OCZ Agility 3, mikor frissen kiadták akkor vettem, emlékszem nem volt ócsó. Még mindig kifogástalanul működik.
---------------------------------------
Devmeme - fejlesztői pillanatok
- A hozzászóláshoz be kell jelentkezni
A rootfs nálam is SSD, csak a /home, swap és a /var nagy része nem az. A /var egyes részei és a /home-ról a böngésző profilok SSD-n vannak, de ez utóbbi esetben nem onnan kerülnek felhasználásra, hanem RAM-ból tmpfs-ről.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
En lassan 3 es fel eve hasznalok egy 128-as SSD-t kizarolag disk cachelesi cellal (Fusion Drive). Minden iras elsore az SSD-re tortenik, majd innen idle I/O eseten kerul at a diskre a tartalom. Ami blokk surun van hasznalva, azt athelyezi a rendszer vissza az SSD-re. Egyelore semmi baja nincs, es ma ha tonkremenne, hamarabb vennek egy uj 256-os SSD-t, minthogy megprobaljam legaranciaztatni a tonkrement jelenlegit.
Ezeknek a cuccoknak evente kb felezodik az ara, mire normal hasznalat mellett 5-7 ev mulva tonkremegy (ha tonkremegy!) a 120-as, rohogorcsot fogsz kapni ha adnak egy masikat, es a jelenlegi 120-as araert vehetsz majd helyette egy 1 vagy 2 terasat.
---
Apple iMac 27"
áéíóöőúüű
- A hozzászóláshoz be kell jelentkezni
Még ha meg is győznétek arról, hogy felesleges a /var-t HDD-n tartani, akkor sem fogom 2 másodperc boot idő csökkenésért felforgatni, amit eddig csináltam. Amúgy variálni akkor is kellene, mert a /var-hoz kicsi az eszköz, a virtuális gépek image-ei is a /var-on vannak, szóbal akkor annak kellene külön filerendszert csinálni a HDD-n.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Nem a boot a legfontosabb, hanem, hogy az egyes programok elindulása, adatok, fájlok betöltése, írása minél gyorsabban menjen.
Azokat célszerű SSD-n tartani, amiket sokszor kell betölteni, gyakran használod és kicsik. Azokat kell HDD-n, amiket ritkán használsz, kevésszer kell betölteni és nagyok.
Én pont fordítva csinálom, a /home, /var SSD-n, filmek, zenék, illetve más nagy, ritkán használatos dolgok HDD-n.
A noatime -ot célszerű bekapcsolni, az sokkal inkább növeli az élettartamot, mint a /home és /var kirakása.
- A hozzászóláshoz be kell jelentkezni
Értem, amit mondasz, de én másként gondolkodtam. Legfontosabb az élettartam, másodlagos, de még mindig fontos a sebesség, hiszen különben minek az egész.
Az oprendszer ugyan napi szinten frissül, de mégis elsősorban olvasásra vesszük igénybe a háttértárat, ezért a rootfs SSD-n van. Így a programok gyorsan indulnak, a magas élettartam sincs veszélyben. A /home-on lévő adatok nem feltétlenül nagyok, így nem tart sokáig az olvasásuk HDD-ről sem, viszont gyakran íródnak, így ez az élettartam miatt marad HDD-n. Hasonlóképpen a /var. A /tmp RAM-disk, pontosabban tmpfs. A böngésző vackaihoz kellene gyorsan hozzáférni, ezért profile-sync-daemon segítségével az RAM-ban van, kikapcsolt gép esetén a HDD-n nyugszik.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
"én másként gondolkodtam. Legfontosabb az élettartam"
Érdemes elolvasni ezt a cikket, főleg a számolgatásokat benne:
http://betanews.com/2014/12/05/modern-ssds-can-last-a-lifetime/
Nagyon nem úgy tűnik, hogy nyersz akármit is azzal, hogy ennyire óvod az SSD-t. Hacsak nem tényleg nagyon hosszú távra tervezel. Veszíteni viszont veszítesz, azt a teljesítményt, ami miatt egyáltalán érdemes volt megvenni, rááldozni az extra pénzt, mondjuk egy sima HDD-vel, vagy egy hibrid meghajtóval szemben.
- A hozzászóláshoz be kell jelentkezni
Épp erről szól a blogom, hogy noha veszítek teljesítményt, de nem sokat akkor, ha a megfelelő könyvtárakat bind-elem.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Had hozzam csak a saját SSD-im adatait (SMART alapján).
Az egyik a munkagépem fő háttértára, 240GB-os Kingston, napi átlag 9 órát megy.
Általában 1000 teljes újraírást mondanak a gyártók, de előfordul, hogy írhatóak 3000-4000-szer is.
A minimum üzemideje 1000*240GB = 240TB írás.
Kb. 1 éves és 3251 órát ment. Ezalatt 4166GB (4,1TB) írás volt rá.
Tehát ez az SSD-m, további ilyen használat mellett, még legalább 58 évig írható maradna.
A másik a feleségem laptopjában, 120GB-os OCZ, napi átlag 1 órát megy, eleinte többet ment, mert a munkagépemből került oda.
A minimum üzemideje 1000*120GB = 120TB írás.
2678 óra alatt 2632GB (2,6TB) írás volt rá, tehát kb. 1 óra alatt 1GB.
Még 117TB-t lehet minimum ráírni, ez napi 1 óra további ilyen használat mellett minimum 320 év.
- A hozzászóláshoz be kell jelentkezni
Az én statisztikám izgalmasabb
Samsung SSD 840 PRO Series
Power_On_Hours = 18318 -> 2 év 1 hónap 2 nap
Total_LBAs_Written = 28542560488 -> 14.6 TB
Feltéve ha jól olvastam el az interneten, hogy a Total_LBAs_Written értékét 512-vel szorozva tudom meg a bájtokat.
- A hozzászóláshoz be kell jelentkezni
---------------------------------------
Devmeme - fejlesztői pillanatok
- A hozzászóláshoz be kell jelentkezni
Akkor én most valamit nem értek. Van mondjuk egy 120 GB-os SSD, gondolom, belül 128 GB. Amit kiajánl, ahhoz nem nyúlhat, hiszen attól, hogy nincs partíció, még lehet használni egyedi rendszerben, vagy közvetlenül filerendszer tenni például az sda-ra. Tehát, ha valamit írunk, az körbe-körbe relokálódhat 8 GB-on. A filerendszer metaadatok viszont gyakran íródnak, például az a rész, ahol a foglaltság van bejegyezve. Jó, van disk cache, ez segít a dolgon. Aztán ott van a journal. Szerintem így mindösszesen 8 TB írásra van lehetőség, ráadásul nem is csak hasznos adat vonatkozásában, hanem a metaadatokat is ideértve. Az viszont nem sok.
Hol hibás a gondolatmenetem?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
"Tehát, ha valamit írunk, az körbe-körbe relokálódhat 8 GB-on."
Itt hibás a gondolatmeneted. Nem csak egy kis részén helyezhet át dolgokat, hanem az egész SSD-n, tehát mind a 120GB-on. Ha egy fs blokkot 1000-szer írsz, akkor a háttérben az SSD vezérlő szépen áthelyezgeti, hogy közel azonos számban legyen minden fizikai blokk írva. Teheti ezt nyugodtan, mert ott nem gáz, ha logikailag egymás mellett levő blokkok fizikailag teljesen máshol vannak.
- A hozzászóláshoz be kell jelentkezni
És valóban! Felületesen arra gondoltam, hogy nem megyünk vele semmire, mert ha értelmes adatot kell arrébb tenni, akkor azt is ki kell írni, olyan lenne ez, mint A legényanyában, ahol is a kiásott föld elhelyezéséhez újabb gödröt ástak. :) Viszont itt annyival másabb a helyzet, hogy nem mindegy, milen sokszor íródik egy-egy szektor.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
"annak kellene külön filerendszert csinálni a HDD-n"
Ő... vagy csak használsz egy nagy partíciót az ssd-n, és egy nagy partíciót a HDD-n.
Hacsak nincs különösebb okod = más fájlrendszert használsz, nem látom értelmét az ilyen szintű darabolásnak, amit leírtál fentebb. Milyen előnyökkel jár az, ha lekorlátozod magadat ezáltal?
Csak azért mondom, mert én is SSD + HDD kombóval nyomulok, a tipikus felhasználás hogy a rendszer SSD-n figyel, az adatok pedig HDD-n.
- A hozzászóláshoz be kell jelentkezni
a tipikus felhasználás hogy a rendszer SSD-n figyel, az adatok pedig HDD-n
Nem ezt csinálom én is? De. :) A rootfs SSD-n, a /home, /var HDD-n, sőt az adatok egy része megint csak SSD-n, nevezetesen az rpm adatbázis annak érdekében, hogy ne őszüljek meg csomagkezeléskor. Ja, és a böngésző profil is SSD-n, bár ott újabb áttétel a profile-sync-daemon. A böngésző profil ugyan SSD-n tárolódik, de csak a gép leállításakor íródik, hiszen használatkor RAM disk-en történik az írás.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
"Nem ezt csinálom én is?"
Igazad van, csak nem teljesen jól fejeztem ki magam. Adatok alatt a felhasználói adatokra gondoltam, minden olyasmire ami az usernek fontos. Persze ez elég szubjektív, de mondjuk az user által közvetlenül előállított tartalom, vagy letöltött cuccok azok, amiket ide értek. Rendszer alatt pedig minden mást, ami feltelepül egy piszkálás nélküli alaptelepítéssel, beleértve a swap partíciót, a home és var mappákat az összes config és cache fájlokkal.
Avagy a tipikus lustaság-egyszerűség esete: Feldobod a rendszert az SSD-re, megy onnan minden, de a nagy dolgokat a HDD-re mented. Nulla config, nulla fejfájás, és mivel a HDD-re kiszervezett cuccok valószínűleg nem igényelnek gyors elérést, nulla teljesítményvesztés.
Persze csupán az én feltételezésem, hogy a tipikus felhasználás ez. Feltételezem hogy sok a nem hozzáértő, vagy az olyanok mint én, akinél a HDD-t egy külső vinyó jelenti, oda nem nagyon szervezel ki /home-t vagy /var-t, ha akarod használni a géped vinyó nélkül is :)
- A hozzászóláshoz be kell jelentkezni
Ezek szerint te notebook-ról beszélsz, az enyém desktop gép, házon belül van a 3.5"-os 500 GB-os HDD és a 2.5"-os 120 GB-os SSD is. Amúgy a /var-t már akkor külön szedtem, amikor csak HDD-m volt. Ennek az az oka, hogy egy esetleges újratelepítés során szerver adatok, virtuális gépek image-ei ne menjenek veszendőbe. Attól tekintsünk el, hogy idejét nem tudom, mikor volt ez a gép telepítve, mindig upgrade-elek. Most a költözés során is file-osan másoltam egy rsync -avHASX forrás cél
paranccsal az oprendszert, utána feltelepítettem az sda-ra a grub-ot, generáltam új initramfs-t, csináltam egy SELinux autorelabeling-et, aztán meg is voltam, szóval eszembe nem jutott, hogy holmi SSD-re költözés miatt telepítsek. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
"Ezek szerint te notebook-ról beszélsz"
Olyan elképzelhetetlen, hogy meglévő desktop gép mellé usb racket vesz az user? Egyébként pont igen, nekem az van, de nem ördögtől való a másik eset sem.
"Ennek az az oka, hogy egy esetleges újratelepítés során [...] ne menjenek veszendőbe."
Azt sejteted, hogy újratelepíteni csak formázással együtt lehet egy rendszert. Én szinte sosem formázom, mindig megtartom azt a pár mappát ami kell nekem, a többit törlöm, és rátelepítem az új rendszert. Semmivel nem bonyolultabb, mint a mount pointokat beállítgatni.
Szóval nekem valahogy nem eléggé indokolja meg az újratelepítés körüli nem létez hacacáré a szétszabdalást.
De kérdem én: Mit csinálsz, ha hozzáadnál egy új virtuális gépet a /var mappád alá, de ott nincs neki elég hely, de mondjuk máshol meg gigák tömege? Nekiállsz partíciót méretezgetni, vagy megtöröd az elvet ami szerint a var alá kerülnek a virt. gépek?
- A hozzászóláshoz be kell jelentkezni
A /var LVM-en van, egyszerűen beteszem a gépbe a másik HDD-met is. A resize2fs online is megy ext4-en, még umount-olni sem kell.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Épp múlt héten vettem meg a 3. ssdmet a notiba (az első kettő is működik deszktopokban), és mindent rápakoltam, ami nem fért rá, és csak néha kell: filmek, isok, ezek symlinkelve vannak a korábbi helyükre.
És még LVM is van rajta, aminek hála a teljes költözést munka mellett, futó rendszeren meg tudtam tenni :-)
- A hozzászóláshoz be kell jelentkezni
Két éve van a kb. 6 éves laptopomban egy 60 gigás SSD. Gyakorlatilag minden ezen van (/, swap, /home, /var), kivéve a zenék, fényképek, letöltött pdf-ek, stb. A home-könyvtár "pótolhatatlan" tartalmáról (a LaTeX-fájlokból készült pdf nem pótolhatatlan, a *.tex fájl viszont igen) rendszeres biztonsági másolat készül a HDD-re (meg még két helyre, laptopon kívül).
Nincs semmi varázslat, két éve (ezzel kapcsolatos) problémát nem tapasztaltam. Azért vettem az SSD-t, hogy (ki)használjam, nem azért, hogy kíméljem.
Nem hinném, hogy ilyen használat esetén váratlanul hamar megy tönkre. De ha mégis, ott van a biztonsági másolatok tömkelege.
- A hozzászóláshoz be kell jelentkezni
Kicsit eljátszottam vele. 8s lett a vége ebből majd 7 a psql, de azt nem kapcsolom ki.
Startup finished in 1.234s (kernel) + 7.394s (userspace) = 8.628s.
$ systemd-analyze blame
6.925s postgresql@9.1-main.service
767ms dev-sda1.device
$ systemd-analyze critical-chain
graphical.target @7.390s
└─multi-user.target @7.390s
└─postgresql.service @7.389s +955us
└─postgresql@9.1-main.service @450ms +6.925s
└─basic.target @429ms
└─sockets.target @429ms
└─acpid.socket @429ms
└─sysinit.target @422ms
└─systemd-backlight@backlight:acpi_video0.service @974ms +17ms
└─system-systemd\x2dbacklight.slice @974ms
└─system.slice @101ms
└─-.slice @99ms
Ez tett csodákat:
systemctl mask NetworkManager-wait-online.service
systemctl mask plymouth-start
Ez már egy elfogadható idő, megpróbálok leszokni az állandó altatásról.
- A hozzászóláshoz be kell jelentkezni
A plymouth-t uninstalláltam, nem tudom, miért áldozunk futásidőt olyan valamire, ami éppen információt takar ki. A NetworkManager-wait-online service-on én is gondolkodtam, elvileg az a lényege, hogy a szerverek ne akkor induljanak el, amikor még nincs hálózat, mert esetleg zokon veszi némelyikük. Ugyanakkor tiltás után engedélyeztem, de valamiért gyors maradt a gép, olyan, mintha senkinek sem kellene:
systemctl status NetworkManager-wait-online
● NetworkManager-wait-online.service - Network Manager Wait Online
Loaded: loaded (/usr/lib/systemd/system/NetworkManager-wait-online.service; enabled; vendor preset: disabled)
Active: inactive (dead)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni