Bcache davon abhalten alle Lesevorgänge zu cachen.

[Piktogramm]

Moin,
ich suche eine Möglichkeit vom Bcache davon abzuhalten alle Lesevorgänge zu cachen!

Zustand:

btrfs data:raid5 meta:raid1c3
bcache0 on /dev/md127	bcache1 on /dev/md127	bcache2 on /dev/md127	bcache3 on /dev/md127
sda	sdb	sdc	sdd

Derzeitiger Stand ist:

• Bcache
  • /sys/block/bcache0/bdi/read_ahead_kb 128
  • /sys/block/bcache0/bcache/sequential_cutoff 4M
• BTRFS
  • /sys/fs/btrfs/<UUID>/bdi/read_ahead_kb 16384

Wenn ich jetzt große Teile der Daten auf dem Dateisystem lese, versucht bcache die gelesenen Daten immer in den Cache zu schreiben. Dabei sind die Dateien im Regelfall >>4M groß und Bcache keine Chance irgendwelche Treffer zu landen, da der Cache naturgemäß deutlich kleiner ist als der Speicher und das Zugriffsmuster keine doppelten Zugriffe bedingt[1].
Was Bcache beim Schreiben der Daten aber auch macht ist, ein großteil der sinnvollen Daten im Cache zu überschreiben (Metadaten vom Btrfs, kleine Dateien, ..)

Die Frage ist nun, kann ich Bcache irgendwie davon abhalten Writes zu cachen? Die Grenze von 4MB die ja bei Schreibvogängen gesetzt ist erscheint mit sinnvoll.

[1]Ok, gelegentlich schon, dass frisst aber der Dateicache im Ram, es macht beim iowait echt keinen Unterschied ob ich Bcache ausschalte oder nicht.

##########################

System ist ein verbasteltes Ubuntu mit 6.11 Kernel

 

[Sensei21]

Wie schaut denn das Szenario aus ?

Welche Art von Daten werden denn verarbeitet ?

um welche Größe handelt es sich ?

 

[Piktogramm]

Das aktuelle Szenario ist, dass viele Videodaten einer Datenwiederherstellung mit ffmpeg decodiert werden um defekte Dateien zu identifizieren, der decodierte Datenstrom ließt in Richtung /dev/null . Größe der Dateien ist zwischen 4MB und 15GB über eine Gesamtgröße von reichlich 2TB (4x die Größe vom Cache). Die 4MB-Dateien sind ein paar GB, würde es die Cache hätte ich kein Problem damit. Die ~2TB großer Dateien werden jedoch nur einmal gelesen.

Das Protokoll vom Test landet auf der SSD vom System, ist also keine Last für den großen Speicher um den es geht.

Bringt halt nix die großen Dateien zu cachen, und mit dem Readahead vom Dateisystem von 16MB sollte der sequential cutoff vom Bcache eigentlich auch überschritten sein, aber der zählt nur für den Schreibcache :/.

 

[foofoobar]

Shared Lib per LD_PRELOAD davor setzen die O_DIRECT bei open(2) setzt.

 

[Sensei21]

/sys/block/bcache0/bdi/read_ahead_kb 128

<-- soll das sich auf bdi beziehen ?

(https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-bdi)

hab bcache noch nicht genutzt, aber laut der dortigen Einstellung, sollte es Folgendes sein ?

/sys/block/bcache0/bcache/queue/read_ahead_kb 128

https://felixmoessbauer.com/blog-reader/tune-bcache-for-large-ssds.html

davon abzuhalten alle Lesevorgänge zu cachen

legitimes und interessantes Nutzungsszenario, eventuall bei Kent Overstreet nachfragen, ob sich das Feature hinzufügen lässt mit einer Option, die das spezifisch setzt ?

 

[Piktogramm]

@Sensei21
read_ahead_kb in bdi und queue sind so oder so identisch für bcache und da btrfs kein /queue anbietet habe ich von beiden /bdi genommen.

Und der Verweis auf Kent, das Interesse an Bcache ist nahe Null, es bcachefs ist angesagt.
Und lustigerweise, laut Dokumentation sollte sequential_cuttoff auch auf Lesevogänge anschlagen, tut es halt nicht.

@foofoobar
O_Direct erzwingt direkten Zugriff auf Blockdevices am Filecache des Kernels vorbei, bcache cached aber das Blockdevice, es ändert sich also nix.


Aber danke fürs Nachfragen, das hat geholfen! Sequential Cutoff ist ja nicht global für das Dateisystem sondern für jedes gecachte Device. Damit ergibt sich ja, dass beim Lesen mit einem 16MB Readahead vom BTRFS der sequential_cutoff vom Cache genau getroffen wird mit 4*4MB. Kaum habe ich den sequential_cutoff auf 1M reduziert sieht das Leben für die SSDs viel entspannter aus. 😅