A Hungarian Unix Portálon láttam egy nagyon érdekes bejegyzést és arra gondoltam, hogy erről azért érdemes egy kis cikket írni, mert Puppy linux alatt is egy igen kedvelt fájlrendszer, sokan használjuk aktívan, ennek főként történelmi okai vannak, hiszen eltérően más linux rendszerektől a Puppy kifejezetten ajánlott pendrive OS.
Aki esetleg még nem találkozott ezzel a megoldással, annak ajánlom a következő videót, ahol egy 8 gigás pendrive -ra telepítünk egy pupletet és bemutatom, hogyan készítem el én a saját megoldásom szerint.
Puppy linux telepítés 8 GB -os USB flash, SSD meghajtóra – videó
No és akkor a lényeg, az eredeti bejegyzés így szól:
Most migrálom az adataimat a régi gép SSD-jéről a másikra, és ezt látom az újon:
root@XXX-mobile:/home# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rootvg-home--lv 320G 308G 13G 97% /home
root@XXX-mobile:/home# du -sh *
267G XXXEz hogy lehet? Azért a ~40 GB eltérés elég combos. F2FS alatt nincs root-nak fentartott százalék, és amúgy is, root-ként annak nem kéne látszania.
Az első parancs a szabad helyet kérdezi le, ami azt mutatja, hogy 308 Gigabyte a foglalt terület, de amikor a du paranccsal kérdezzük le, mennyi az összes fájl által elfoglalt tárterület, az bizony csupán 267 Gigabyte… ez valóban elég érdekes… és itt jön a DE !
Az SSD meghajtók úgynevezett FTL (flash translation layer) -t tartalmaznak (firmware), ami azért felel, hogy az eszközünk tovább éljen mint egy hagyományos SD kártya.
Ezt úgy éri el, hogy folyamatosan figyeli az írási igényeket és társítja a megfelelő fizikai szektorokat az operációs rendszer számára ténylegesen írható egységekké, ezt nevezzük mapping -nak.
Tehát az írás soha nem folyamatos az eszközön, nem ész nélkül ír mindenhová, hanem egységes logikai helyet kapunk és amikor egy nagyobb írási folyamat érkezik, azt a már kialakított, egységes szektorcsoportba fogjuk írni, ettől megnő a lemez élettartama és az olvasás is nagyobb egységekben válik lehetővé.
Az F2FS (Flash-Friendly FileSystem) működési elve így már érthető módon naplózás alapú ám két helyen is történik könyvelés, az egyik a firmware a másik az operációs rendszer.
Ebből az is következik, hogy az FTL nem fog minden esetben kotorászni és írkálni a lemezen, hogy kímélje a tárolót és következésképpen nem is fog látszódni minden esemény, úgymond nem lesz feltétlenül minden esemény jelentve.
Amikor írás történik, az szépen sorban megy a következő üres helyre és még az is megeshet, hogy nem látszik elegendő szabad hely a rendszeren, de ilyen esetekben a használt, különálló szektorok adatait egy helyre pakolja és létrehozza az új szabad régiót a következő írásra. A szektorok átrendezését relokációnak is hívjuk és a felszabaduló hely miatt ezt a procedúrát pedig cleaning -nek.
Így már érthető, hogy az FTL mindig zsebre tesz magának suttyomban egy kis tárhelyet a cleaning -re, de a szemfüles rendszergazda tudja, hogy mi lapul ott ezért mindig túlírja, ezt hívjuk over-provisioning -nek.
Az okos rendszergazda viszont sosem írja túl, mert ilyenkor az FTL elmegy szabadságra és nem fog többé foglalkozni relokációval és az adatok új metódussal kerünek kiírásra, magyarul ezt úgy is hívjuk, ahogy esik, úgy puffan. Ahol hely van, oda lesz kiírva az adat.
Értelemszerűen az adatok kinyerése érdekében többet kell dolgozni, ezeket több idő kiolvasni, az SSD elérése és működése lassul, használata nehézkesebb, szóval ne használjuk ki az over-provisioninget, ha nem muszáj.
A két log elvű működés miatt tehát gyakran tapasztalható eltérés és furcsaság a rendszerből lekérdezett és a tényleges fizikai adattárolón kialakult helyzetből adódóan, erre a megoldás mindig a cleaning, ami vagy használat közben megy végbe, ez hívjuk úgy, hogy on-demand, tehát kérésre, vagy a kernel elvégzi a számítógép szabadidejében, amikor úgynevezett idle módban van.
Lazán kapcsolódik a dologhoz, hogy a Windows10 miért vágta haza egy időben az SSD meghajtókat:
értelemszerűen nincs szükség töredezettségmentesítésre (defrag), hiszen a szektorok mindig szép, katonás rendben vannak, a windows ennek ellenére egy hiba folytán folyamatosan lefuttatta ezekre is, így ezek minimum kétszeres defragmentációt jelentenek szerencsétlen meghajtónak, mivel egy már alapból fut az FTL -ben…
További részletek és részletes leírás az alábbi linken: https://lwn.net/Articles/518988/