F2FS diszk használat

Naplózó filerendszerek (journaling)

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    XXX

Ez 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.

  • 422 megtekintés

( uid_18128 | 2021. 05. 21., p – 07:16 )

Szerkesztve: 2021. 05. 21., p – 08:54

A cleaning lesz a kulcs és a két helyes log struktúra,  mivel az FTL nem érzi lényeges dolognak a szabad területekkel való foglalkozást és annak lejelentését, így az csak a cleaning procedúra folyamán szabadul fel ténylegesen, ebben tér el a hagyományos fájlrendszerektől.

Handling filesystem-full conditions in traditional filesystems is relatively easy. If no space is left, you just return an error. With a log-structured filesystem, it isn't that easy. There might be a lot of free space, but it might all be in different sections and so it cannot be used until those sections are "cleaned", with the live data packed more densely into fewer sections. It usually makes sense to over-provision a log-structured filesystem so there are always free sections to copy data to for cleaning.

https://lwn.net/Articles/518988/

Köszönöm szépen a korrekt összefoglalót! Így már világos(abb) a dolog.
Sajnos a cleaning alapból nem történik meg idle időben (legalábbis a gépem elég idle volt az elmúlt 24 órában), de a used/free mennyiség nem változott, overprovision-nek azért combos az x>10% érték.
Növeltem FS méretet is, de attól sem csökkent a used mennyiség. (Mily meglepő.)

... The vision and the mission lost,
For those with corporate souls ...

Slackware Linux current | 5.10.38-janos

Mert lehetőség szerint szeretném, hogy az SSD-im minél hatékonyabban legyenek használva.
A trim csak az egyik szempont, azt az F2FS defaultból tudja. De az FS naplózás is vélhetőleg másképp történik, illetve a copy-on-write-os adattárolás is az írási műveletek jobb kiegyensúlyozását szolgálja.
Szóval röviden ezért.

... The vision and the mission lost,
For those with corporate souls ...

Slackware Linux current | 5.10.38-janos

off

Szerintem defrag nem csak azért nem kell, mert sorrendben vannak a file adatához tartozó szektorok, hanem azért, mert flash memória esetén nincs fejmozgás, nincs seek time, így a hozzáférési idő nem sokkal nagyobb random, mint szekvenciálisan. Kicsit talán neagyobb, mert címet újra mondani kell, nem lehet burst-ösen, auto-increment címmel elérni a szektorokat, de a SATA kommunikáció gyors. Mindenképp gyorsabb, mint a HDD-k fejmozgatása.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( wowbagger v | 2021. 05. 21., p – 15:44 )

Számomra némileg meglepő módon, mikor újra létrehoztam a fájlrendszert az Arch wiki által ajánlott opciókkal, akkor a következő eredményt kaptam:

root@XXX-mobile:~# mkfs.f2fs -l home -O extra_attr,inode_checksum,sb_checksum,compression /dev/rootvg/home-lv
...
root@XXX-mobile:~# df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/rootvg-home--lv      360G  272G   89G  76% /home
root@XXX-mobile:~# cd /home
root@XXX-mobile:/home# du -sh *
267G    XXX

Note: bár a compression feature-t bekapcsoltam, mount-olásnál nem adtam meg semmit a javasolt compress_algorithm és  compress_extension opciókat, illetve egy könyvtárra sem kapcsoltam be a tömörítést.

... The vision and the mission lost,
For those with corporate souls ...

Slackware Linux current | 5.10.38-janos

Az f2fs ilyen, nekem sincs vele jó tapasztalatom. Csomó minden nem szerette, mikor én próbáltam, pl. fstrim. Valójában nem SSD-re való, hanem memóriakártyákra, ahol nincs aktív vezérlés, nincs FLT, garbage collection, stb.. SSD-nél vannak ilyenek, ott az aktív vezérlő gondoskodik ezekről. Használj helyette ext4-et, egyszerűbb, gyorsabb, jó pár éve kiérett fájlrendszer, minden tool és disztró hibátlanul kezeli. SSD-re is ez vált be nekem a legjobban. Igaz én nem is extra checksumozom, meg nem használok röptömörítést sem. Ha nem elég a tárhely, veszek nagyobb meghajtót, SSD-t.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Hát, a cucc már ~10 éve kint van, és a leírás épp azt mondja, hogy az f2fs FTL-es, "okosított" flash tárolókra (SSB, memóriakártyák) való. Amire Te gondolsz, az a jffs2 lehet, ami valóban mtd-s flash eszközökre készült.

... The vision and the mission lost,
For those with corporate souls ...

Slackware Linux current | 5.10.38-janos

Akkor erre lehet rosszul emlékeztem, hogy FTL-esre is való. De a lényegben nem tévedek, hogy nem SSD-re találták ki. Sokan úgy reklámozzák, meg a Phoronix is hájpolni szokta a benchmarkjain, de nem valami jó fájlredszer desktop/szerver gép SSD-jére. A jffs2 sem. A jól bevált, default fájlrendszereknél kell maradni, amik már bizonyítottak hosszú távon. Persze, próbálkozni lehet, meg technikai érdekességként egy nem kritikus drive-on próbálgatni, csak komolyan nem érdemes venni. Nálam az ext4 nagyon csúnyán elveri, random I/O, betöltési idők, TRIM-elési idő, fsck, stb., köröket fut köré.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Pendrive-ra okés, mert az nem kap sok írást, meg az USB bottleneck miatt nem annyira teljesítményspecifikus, meg nem írsz rá annyit. Azt majdnem mindegy mire formázod, ext2, ext4, f2fs, jfs, exfat, ntfs, vagy ami tetszik. De én fontos adataim és rendszer alá nem raknám.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Az f2fs éppen azzal kíméli a flash-t, hogy lényegében egy hatalmas körbeforgó naplónak gondolja magát. Szóval éppen bírnia kell a sok írást, mert az a lényege, hogy nem mindig ugyanazok a szektorok vannak gyötörve.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Így van. De mint írtam, egy pendrive-ra tipikusan nem írsz sokat, meg az USB bottleneck is ott van, így annyira nem lényeges, hogy milyen fájlrendszer van rajta. Ext4-gyel sem írod szét, hacsak nem futtatsz róla napi OS-t vagy valami extrém használatra nem fogod be, amire nem való. Ami sok írást kap, azt SSD-re tenném, annak a vezérlője gondoskodik a wear levelingről, eleve gyakran pendrive helyett már külső SSD-t használok, vagyis belső, de USB-SATA adapterrel, OS telepítésekre forrásnak, célnak, vagy amire kell. Nem is főként az írásmennyiség miatt, hanem a sebesség miatt is.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”