Arch Linux

f2fs compression funktioniert nicht

brikler

grüß euch,

wie der titel sagt, die compression funktioniert nicht, und kann leider auch nicht funktionieren, weil :

[  290.754919] cachyos kernel: F2FS-fs (nvme0n1p1): Image doesn't support compression
[  424.343021] cachyos kernel: F2FS-fs (nvme0n1p1): Image doesn't support compression
[  433.322027] cachyos kernel: F2FS-fs (nvme0n1p1): Image doesn't support compression

ich habs mit zstd, lzo, und lz4 versucht
sudo mount -o remount,compress_algorithm=lz4 /

hat zufällig jemand, irgendwo was von einer problemlösung gelesen?
es gibt zwar einige threads die sich damit befassen, aber eine lösung war nicht dabei 🙁

leider bringt mich die suchmaschine des geringsten mißtrauens auch nicht weiter 🙁

GerBra

Wahrscheinlich weil die Option compression beim Erstellen des Dateisystems nicht angegeben wurde.

Ich kriege die gleiche Meldung wenn ich das FS z.B. wie im Wiki:
https://wiki.archlinux.org/title/F2FS#Creating_a_F2FS_file_system
erstelle, also nur mit -O extra_attr,inode_checksum,sb_checksum.

Wenn ich dann die Features prüfe:

# fsck.f2fs --dry-run /dev/loop0 |grep superblock
Info: superblock features = 828 :  extra_attr inode_checksum sb_checksum
Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000

werden mir auch nur diese angezeigt. Und eben keine Kompression.
fsck funktioniert aber nur wenn das FS nicht gemountet ist, eine andere Möglichkeit Infos zum Heade/Features des f2fs-Dateisystems zu erhalten kenne ich nicht mangels Erfahrung damit. Du müßtest es also "offline" (boot-iso) machen da das ja dein Root-FS ist.
//Edit2
Ob dein Dateisystem überhaupt Kompression kann ist auch über die Ausgaben von mount/findmnt erkennbar.
Wenn das FS mit Kompressions-Option erstellt wurde dann taucht bei den Mount-Ausgaben auf:
compress_algorithm=zstd:1,compress_log_size=2,compress_mode=fs
Zumindest compress_mode ist wohl ein entscheidender Hinweis ob das FS überhaupt mit Kompression erstellt wurde.

Erstelle ich das FS mit compression dann wird das auch angeführt:

# fsck.f2fs --dry-run /dev/loop0 |grep superblock
Info: superblock features = 2828 :  extra_attr inode_checksum sb_checksum compression
Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000

Ohne "Neuformatierung" wird das wohl nichts mit Kompression, ich habe am Image mal testweise die fsck.f2fs Optionen "-O compression" oder "-g compression" versucht, aber es scheint nicht möglich (zumindest mit meiner Nicht-Erfahrung bzgl. f2fs) nachträglich dem FS andere Optionen/Features zu geben. Was bei compression ja sowieso nur neu erstellte Dateien behandeln würde wenn es gehen würde.

//Edit
Du kannst ja gerne mal selbst mit/an einem Image testen

# dd if=/dev/zero of=f2fs-test.img bs=1M count=200
# losetup --find --show f2fs-test.img

Erzeugt dir das Device /dev/loop0 mit rund 200MB. Damit kannst du dann mkfs.f2fs mit den o.a. Optionen/Test erstellen und auch irgendwohin mounten/testen.

Wenn man Kompression will bei f2fs muss es explizit als Option mitgegeben werden beim Formatieren.

brikler

GerBra danke dir, ich werds versuchen 🙂
allerdings, steht davon nichts in der dkumentation (oder ich habs überlesen, bzw schlicht nicht kapiert).

edit:
wenn mans so macht wies im wiki steht, dann gehts

sudo fsck.f2fs --dry-run /dev/nvme0n1p3 |grep superblock
Info: superblock features = 2828 :  extra_attr inode_checksum sb_checksum compression
Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000

GerBra

brikler wenn mans so macht wies im wiki steht, dann gehts

Ja, ich habe aus Spaß auch gerade nochmal getestet. Die Dokumentation (selbst man mkfs.f2fs) ist bzgl. der Features für Anwender nicht sehr zielsicher. Anders hingegen unser Wiki, so zumindest bei der Erstellung des Dateisystems aufgeführt wird: Willst du compression dann mußt du diese Optionen setzen - und zwar beim Erstellen des FS.

Zu dem, was ein aktuelles F2FS-Dateisystem kann finden sich die Infos zu einem eingehängten FS hier:
(Bei mir ist das Blockdevice loop2, bei dir nvme0n1p3)
/sys/fs/f2fs/loop2/feature_list
Ich nutze gerne den mc zum anschauen der Dateien darin.

Ohne explizite Angabe von compression beim Formatieren hat ein f2fs:

$ cat /sys/fs/f2fs/loop2/feature_list/compression 
unsupported

Deshalb auch die Fehlermeldung aus dem Eingangspost bzw. den Logs: Image doesn't support compression

Kompression ist per Default halt nicht eingeschaltet, ein simples:
mkfs.f2fs /dev/whatever
aktiviert gar kein "Feature", weder compression noch encrypt noch die, welche im Wiki-Artikel noch empfohlen werden.

Und es läßt sich halt, anders als bei anderes Dateisystemen, nachträglich - also ohne Neuformatierung - kaum etwas ändern.
Die einzige Option die ich gefunden habe, die nachträglich zuschaltbar wäre ist:
fsck.f2fs -O encrypt /dev/loop2
Das wird in der Ausgabe auch erwähnt und ist dann auch bei /sys/fs/f2fs/loop2/feature_list/encrypt danach als "supported" markiert. Ob und wie es dann funktioniert ist eine andere Geschichte.
Der Versuch compression nachträglich zuzuschalten mißlingt. Für Kompression müssen zwingend diese beiden Features "aktiv" sein: extra_attr und compression. Trotzdem funktioniert:
fsck.f2fs -O extra_attr,inode_checksum,sb_checksum,compression /dev/loop2
nicht, der Status für compression bleibt weiterhin "unsupported" in der aktiven Featureliste nach einem Neumount. Und auch kein anderes dieser verwendeten Features ist danach aktiv.

Also:
Will man bei F2FS bestimmte Möglichkeiten haben (Kompression, Verschlüsselung, etc.) dann muß das beim Erstellen (Formatieren) explizit angegeben werden (-O feature1,feature2,...).
Nachträglich geht das nicht ohne Neuformatierung (Verlust der bestehenden Daten).
Kompression bedingt diese beiden Features: mkfs.f2fs -O extra_attr,compression
Die anderen im Wiki-Artikel verwendeten Optionen sind sicher auch nicht verkehrt:
https://wiki.archlinux.org/title/F2FS#Creating_a_F2FS_file_system

brikler

GerBra es bleibt spannend 😉

/dev/nvme0n1p3 /mnt f2fs 
rw,lazytime,relatime,background_gc=on,nogc_merge,discard,discard_unit=block,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,barrier,extent_cache,mode=adaptive,active_logs=6,alloc_mode=reuse,checkpoint_merge,fsync_mode=posix,compress_algorithm=zstd:6,compress_log_size=2,compress_extension=jpg,compress_mode=fs,memory=normal,errors=continue 0 0

aber nach dem ich ein paar bilder hin kopiert hab:

sudo cat /sys/kernel/debug/f2fs/status | grep compress
  - compress:    0, hit:       0
  - compress:    0, hit:       0

und auch das mag nicht so wie ich…

sudo chattr -V +c /mnt/Bilder/bluemche.jpg
chattr 1.47.2 (1-Jan-2025)
Flags of /mnt/Bilder/bluemche.jpg set as --------c-------------
chattr: Invalid argument while setting flags on /mnt/Bilder/bluemche.jpg

GerBra

brikler es bleibt spannend

Nu ja...

Also ich habe mich nun genug mit f2fs beschäftigt - mit meinen bescheidenden Kenntnissen. Mein Fazit: ich würde es nicht nutzen.
//Edit2: Zumindest nicht auf herkömmlichen SSDs/NVMEs in "normalen" Computern. Das FS mag sinnvoll sein für FlashCards/Handys(Android nutzt es AFAIK) oder z.B. in einem Raspi (wobei in meinem Uralt-Raspi mit Speicherkarte ext4 auch bisher nie versagte...)

Zur Kompression: Auch wenn compression aktiv ist scheint es IMHO daß das Dateisystem nicht transparent sinnvoll Daten/Blöcke/Inodes komprimiert.
Ich würde von einem intelligenten Dateisystem erwarten z.B. einen Block der zu einem ZIP oder JPEG gehrt nicht versucht zu komprimieren, andere gut komprimierbare hingegen schon - und zwar ohne mein Zutun.
Und da bin ich mir bei f2fs nicht sicher.

Ich habe bei meinen tests keine bestimmte Extension eingeschränkt/bevorzugt (übrigens: dein Test mit jpg ist wohl eher suboptimal, die sind ja schon "komprimiert").

Vorweg: Ich sehe mich außerstande irgendwo bei f2fs das Ratio zwischen unkomprimiert und ggf. komprimiert sicher rauszulesen. Und das geht anderen wohl auch so:
https://unix.stackexchange.com/questions/611976/how-to-i-find-f2fs-compression-ratio
https://bbs.archlinux.org/viewtopic.php?id=262364

Ich sehe nur - wenn ich das FS mit komprimierbaren Daten zuschütte - daß scheinbar etwas komprimiert wird:
less /sys/kernel/debug/f2fs/status

Utilization: 94% (37258 valid blocks, 0 discard blocks)                                                              
  - Node: 120 (Inode: 95, Other: 25)                                                                                 
  - Data: 37138                                                                                                      
  - Inline_xattr Inode: 94                                                                                           
  - Inline_data Inode: 0                                                                                             
  - Inline_dentry Inode: 3                                                                                           
  - Compressed Inode: 79, Blocks: 1852                                                                               
  - Swapfile Inode: 0                                                                                                
  - Donate Inode: 0                                                                                                  
  - Orphan/Append/Update Inode: 0, 0, 0

NB: dein "grep compress" im status File: Da erwischst du ja nur die Zeile aus der Sektion "Balancing F2FS Async:" - und da glaube ich fast nicht das dort was Aussagekräftiges zu Compress-Ratio drin ist.

Ich hätte erwartet, etwas in:
# cat /sys/fs/f2fs/loop0/compress_percent
zu finden, aber das bleibt bei 0. Lediglich bei den anderen (sinnvollen?) Statusfiles:

# ls -1 /sys/fs/f2fs/loop0/compr*
/sys/fs/f2fs/loop0/compress_percent
/sys/fs/f2fs/loop0/compress_watermark
/sys/fs/f2fs/loop0/compr_new_inode
/sys/fs/f2fs/loop0/compr_saved_block
/sys/fs/f2fs/loop0/compr_written_block

sehe ich "Bewegung" drin.

Aber auch erst, seit ich mit chattr das ganze gemountete Verzeichniss "behandelt" habe.

Zu deiner Fehlermeldung: "chattr: Invalid argument while setting flags"...
Habe ich auch. Entgegen der Doku ist es aktuell scheinbar nicht möglich für einzelne Dateien das c-Flag zu setzen. Es funktioniert hingegen bei Verzeichnissen.

Mein Test-FS ist eingehängt unter:
/mnt/f2fs
Ich habe vor dem Kopieren nun dieses Verzeichnis "behandelt"
chattr +c /mnt/f2fs
(-R/--recursive funktioniuert nicht, da dann wieder o.a. Fehlermeldung invalid argument auftaucht)
Dateien/Dirs die ich dann kopierte, verschob haben dann das c-Flag
lsattr -R /mnt/f2fs/|less

Mit meinem 94% Full dateisystem sehe ich nun zwischen du und df Ausgaben schon einen Unterschied, aber ob daß (per Kopfrechnen) ein Compress-Ratio ist?
Oder ist es halt mit "Kompression" etwas Religiöses ;-) Entweder man glaubt dran oder nicht...

NB: Das würde sich auch mit der "spärlichen" Doku zu Kompression (aus Usersicht) in den Kernel-Doks decken
https://docs.kernel.org/filesystems/f2fs.html#compression-implementation
So weit ich das verstehe <g>:

Dieser erste Cluster-Absatz scheint daraufg hinzudeuten ob und wann f2fs komprimiert
Wenn ich es "provozieren" will, dann muß ich mit chattr Verzeichnisse bearbeiten (c-Flag setzen, Compress dann bei neuen oder "angefassten" Dateien) - also "per Hand"

Ziel beim "Komprimieren" ist halt Zugriffsvermeidung, und nicht primär "spare riesigen Speicherplatz" - das gilt wohl für alle Dateissteme die Kompression anbieten.:

"At this point, compression feature doesn’t expose compressed space to user directly ... 
Instead, the main goal is to reduce data writes to flash disk as much as possible..."

Ich habe bei meinem BTRFS auf dem Server auch compression eingeschaltet, evtl. schau ich da mal ob ich das ein Ratio eher entdecke... Habe mich darum nie sonderlich gekümmert.
//Edit: Ich habe mal geschaut, da ist wenigstens was zu sehen für den User <g>:

# compsize /usr/share/
Processed 47775 files, 11724 regular extents (11749 refs), 37358 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL       44%      184M         419M         419M       
none       100%       73M          73M          73M       
zstd        32%      111M         345M         346M

Ganz beachtlich bei Daten die sich gut komprimieren lassen.
Bilder hingegen (vornehmlich jpg/png):

# compsize /data/Media/bilder/
Processed 1347 files, 1221 regular extents (1221 refs), 176 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL       96%      141M         147M         147M       
none       100%      139M         139M         139M       
zstd        26%      2.0M         7.6M         7.6M

Aber meine Tests mit f2fs sind erstmal genug...

brikler

GerBra danke dir, das war wie immer sehr hilfreich 🙂
auf jeden fall tut es was, obs was gutes ist, teht auf einem anderen blatt 😉

du /usr/bin/ -h
3.5K /usr/bin/vendor_perl
280K /usr/bin/db5.3
646K /usr/bin/core_perl
3.5K /usr/bin/site_perl
335M /usr/bin/

du /mnt/bin/ -h
280K	/mnt/bin/db5.3
3.5K	/mnt/bin/site_perl
700K	/mnt/bin/core_perl
3.5K	/mnt/bin/vendor_perl
350M	/mnt/bin/

GerBra

GerBra Zu deiner Fehlermeldung: "chattr: Invalid argument while setting flags"...
Habe ich auch. Entgegen der Doku ist es aktuell scheinbar nicht möglich für einzelne Dateien das c-Flag zu setzen. Es funktioniert hingegen bei Verzeichnissen.

In dem Fall wäre das
sudo chattr +c /usr/lib/
AFAIK sollten dann alle neuen oder veränderten Dateien (eventuell!) komprimiert werden (also das c-Flag haben bei lsattr)

GerBra Ich habe vor dem Kopieren nun dieses Verzeichnis "behandelt"
chattr +c /mnt/f2fs
(-R/--recursive funktioniuert nicht, da dann wieder o.a. Fehlermeldung invalid argument auftaucht)
Dateien/Dirs die ich dann kopierte, verschob haben dann das c-Flag
lsattr -R /mnt/f2fs/|less

//Edit: IMHO ist diese ganze Kompressions-Implementation bei f2fs einfach aktuell nur Humbug...

brikler

so ganz versteh ich das mit der daten compression noch nicht 🙁

To enable compression on regular inode, there are four ways:
chattr +c file
chattr +c dir; touch dir/file
mount w/ -o compress_extension=ext; touch file.ext
mount w/ -o compress_extension=*; touch any_file

To disable compression on regular inode, there are two ways:
chattr -c file
mount w/ -o nocompress_extension=ext; touch file.ext

Priority in between FS_COMPR_FL, FS_NOCOMP_FS, extensions:
compress_extension=so; nocompress_extension=zip; chattr +c dir; touch dir/foo.so; touch dir/bar.zip; touch dir/baz.txt; then foo.so and baz.txt should be compresse, bar.zip should be non-compressed. chattr +c dir/bar.zip can enable compress on bar.zip.
compress_extension=so; nocompress_extension=zip; chattr -c dir; touch dir/foo.so; touch dir/bar.zip; touch dir/baz.txt; then foo.so should be compresse, bar.zip and baz.txt should be non-compressed. chattr+c dir/bar.zip; chattr+c dir/baz.txt; can enable compress on bar.zip and baz.txt.

 cat /proc/mounts | grep f2fs
/dev/nvme0n1p1 / f2fs rw,lazytime,relatime,background_gc=on,gc_merge,discard,discard_unit=block,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,barrier,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,checkpoint_merge,fsync_mode=posix,compress_algorithm=lz4,compress_log_size=2,compress_extension=so,compress_chksum,compress_mode=fs,memory=normal,errors=continue 0 0

sudo chattr -R +c /usr/lib/libabsl_base.so
chattr: Die Operation wird nicht unterstützt beim Lesens der F doch klags in /usr/lib/libabsl_base.so

eigentlich müsste das komprimiert werden, oder hab ich da was fundamental falsch verstanden?

brikler

GerBra chattr +c, tut schon was, aber nicht bei allen, zb:

─>$ sudo chattr +c /usr/lib/grcrt1.o
┬─Mi  2.07.25 10:46  ~
╰─>$ sudo lsattr /usr/lib/grcrt1.o
--------c------------- /usr/lib/grcrt1.o
┬─Mi  2.07.25 10:47  ~
╰─>$ sudo chattr +c /usr/lib/libtss2-rc.so
chattr: Die Operation wird nicht unterstützt beim Lesens der Flags in /usr/lib/libtss2-rc.so
┬─Mi  2.07.25 10:48  ~
╰─>$ sudo lsattr /usr/lib/libtss2-rc.so
lsattr: Die Operation wird nicht unterstützt Beim Lesen der Flags von /usr/lib/libtss2-rc.so

aber es stimmt schon, für den benutzer könnte es bequemer umgesestzt sein

GerBra

brikler ─>$ sudo chattr +c /usr/lib/grcrt1.o
┬─Mi 2.07.25 10:46 ~
╰─>$ sudo lsattr /usr/lib/grcrt1.o
--------c------------- /usr/lib/grcrt1.o

Das ist eine reguläre Datei, damit scheint es zu gehen wie in der Doku angegeben.

brikler ┬─Mi 2.07.25 10:47 ~
╰─>$ sudo chattr +c /usr/lib/libtss2-rc.so
chattr: Die Operation wird nicht unterstützt beim Lesens der Flags in /usr/lib/libtss2-rc.so

Das ist ein symbolischer Link. Da kommt (wohl zurecht) die Meldung.
stat /usr/lib/libtss2-rc.so

Soweit ich mich an meine obigen Tests noch erinnere:
Gesetzte c-Attribute bei Verzeichnissen werden für neue (evtl. auch für geänderte) Verzeichnisse und darin enthaltene Dateien weiter vererbt.
Deshalb bin ich bei meinem Test mit dem f2fs-Image hingegangen und habe das noch leere' eingehängte FS (/mnt/f2fs) mit dem c-Flag versetzt - danach hatten kopierte Daten das Flag auch (geerbt)

Um dein aktuelles Dateisystem zu "behandeln" könntest du jetzt evtl.:
a) chattr -R +c /
machen und ggf. die Fehlermeldungen ignorieren, aber stichprobenartig nachprüfen ob wirklich alle normalen Verzeichnisse und Dateien jetzt das c-Flag haben.
b) Du arbeitest mit find und xargs und läßt damit chattr nur auf reguläre Dirs/Files los.
Das kann find (siehe man find //Edit Parameter -type)

Generell zu f2fs auf deinem richtigen Rechner: Du hast ja keine richtige Kontrolle ob compression wirkt und wenn, welche Wirkung das für dich als User hat. Hatten wir schon diskutiert, es gibt kein "Hilfstool" was dir Infos zur Kompression anzeigt (anderes bei BTRFS).
Das Ziel von compression bei f2fs ist ja laut Doku: Reduzierung von Zugriffen auf Speicherzellen, nicht die Optimierung dem User unbedingt den gesparten Speicherplatz zur Verfügung zur stellen.
Nimm es also einfach hin, das es ggf. "irgendetwas sinnvolles" tut.

Zum Testen würde ich dir wirklich raten, wie ich oben ein mit dd erzeugtes Image als f2fs zu formatieren (mit compression eben), und das irgendwo einhängen. Das muß ja nicht groß sein, zum Rumtesten langen ja rund 200MB.
Damit lönntest du aber schnell Dinge testen:

wird das c-Flag wirklich vererbt (wenn zu z.B. auf das leere eingehängte Dateisystem chattr +c machst, auf den Einhängepunkt).
werden Dateien die sich gut komprimieren lassen wirklich komprimiert?
Das ist schwer (da kein Tool) rauszukriegen, außer ggf. durch Kopfrechnen zwischen den Ausgaben von "du"(bzw. du --apparent-size) und "df"
Ein guter Test wäre z.B. - das habe ich nicht mehr gemacht - :
erzeuge auf dem Test-FS (bzw. Kopiere dahin) eine erneute Datei die nur aus Nullen besteht (erzeuge also eine weitere Datei mittels; dd if=/dev/zero). Angenommen dein Test-FS mit Compress hat 200MB und du kopierst dahin eine 50MB große Datei aus Nullen: das müßte sich in der Ausgabe von du/df eigentlich bemerkbar machen da diese Datei sich auf wenige Kilobyte komprimieren lassen sollte.

Beachte beim Arbeiten mit einem Test-Image als f2fs allerdings:
Sowohl die mit dd erzeugte Image-Datei (über die du mit losetup arbeitest) als auch das Einhänge-Verzeichniss sollten auf deinem Rechner(Host) in einem Verzeichniss liegen was nicht das c-Flag gesetzt hat! Ansonsten gäbe es ja wohl unerwünschte "Seiteneffekte" durch ggf. "doppelte Kompressions-Versuche, einmal vom Host-FS und dann vom Test-FS).
Ich würde mir ein Dir anlegen wie:
/test
und diesem das c-Flag entziehen.
Darin dann das per dd erzeugte Test-Image erstellen (ebenfalls überprüfen das dieses kein c-Flag hat)
Als Mount/Einhänge-Verzeichnis dann:
/test/mnt
(auch prüfen das diesen Dir ohne eingehängtes test-image kein c-Flag hat).

Wie gesagt: viel Aufwand für ein etwaig zweifelhaftes "Feature" - aber nur durch sauberes Testen kannst du rauskriegen, ob in deinem "richtigen" Dateisystem (Host) langfristig irgendwas eine Auswirkung hat.

________ OT __________

Ein generelles Gedanke zu Dateisystemen, die Kopmression unterstützen:
Backups sind noch verpflichtender!
Wenn ich jemals gezwungen bin (kaputtgehende Festplatte z.B.) darauf oder einem Image auf unterster Blockebene "irgendwas" zu suchen oder wiederherzustellen, also ohne das Dateisystem benutzen zu können - mit Tools/Procedere wie mit testdisk/photorec oder strings nach einem bestimmten Textfragment zu suchen:

auf einem FS ohne Kompression habe ich da gute Chancen, da ein "Text" meist in seiner reinen, kompletten Form irgendwo liegt.
auf einem FS mit Kompression ist es eher unwahrscheinlich, daß ich etwas finde. Da der "Text" durch irgendeinen Algorithmus ja wohl eben nicht mehr in seiner ursprünglichen reinen Form vorliegt. Ohne Tools, die nicht eben auch diese Algorithmen benutzen, bin uch auf dieser untersten Ebene wohl eher aufgeschmissen beim Versuch eines Restore.

//Edit 2:
Backups sind noch verpflichtender!
Ich nutze z.B. BTRFS mit Kompression auf meinem Server. Backups erzeuge ich u.a. in dem ich Snapshots per "btrfs send" auf ein ebenfalls mit BTRFS formatiertes externes Device sende (btrfs receive).
Dieses externe Device ist "natürlich", wohlweislich OHNE Kompression (oder auch andere BTRFS-Features) angelegt! Sonst käme ich ja "vom Regen in die Traufe" ;-)
//Edit3: Da - wenn ich das Backup brauche - dann ist das Backup keine KOPIE mehr der "Daten", sondern es SIND die "Daten". Und da sollte man so konservativ wie möglich sein...

brikler

GerBra a) chattr -R +c /
machen und ggf. die Fehlermeldungen ignorieren, aber stichprobenartig nachprüfen ob wirklich alle normalen Verzeichnisse und Dateien jetzt das c-Flag haben.

das flag haben sie, interessant wirds erst, wenn ein update eingespielt wird, ob die das flag auch haben werden, aber ich bin zuversichtlich 🙂

edit: es funktioniert 😃

╰─>$ cat /sys/fs/f2fs/nvme0n1p1/compr_new_inode 
734
┬─Mi  2.07.25 13:32  ~
╰─>$ cat /sys/fs/f2fs/nvme0n1p1/compr_saved_block 
2156
┬─Mi  2.07.25 13:34  ~
╰─>$ cat /sys/fs/f2fs/nvme0n1p1/compr_written_block 
2152

edit nach einem update:

╰─>$ cat /sys/fs/f2fs/nvme0n1p1/compr_new_inode
1810
┬─Do  3.07.25 13:12  ~
╰─>$ cat /sys/fs/f2fs/nvme0n1p1/compr_saved_block 
28735
┬─Do  3.07.25 13:13  ~
╰─>$ cat /sys/fs/f2fs/nvme0n1p1/compr_written_block 
30837