SSDCache aktivieren oder deaktivieren funktioniert nicht mehr (config deadlock?)

Hallo zusammen,

ich habe hier grade ein recht sonderbares Problem. Mir ist aufgefallen, dass meine drehenden Platten neuerdings wieder deutlich mehr zu arbeiten hatten als gewohnt. Denn normalerweise haben die meisten meiner Volumes nen Read/Write Cache in Form von 2 128GB kleinen SSDs im RAID1 Verbund vorgeschaltet. Das hat die letzten 2-3 Jahre auch anstandslos funktioniert. NAS hat auch ne USV.

Nun ja, ich sah dann auch, dass die eigentlich üblichen ~99% Write-Hit gen 0% gegangen sind.

Wie es scheint, war der Cache zwar global aktiviert, aber für kein Volume angehakerlt.

1. Versuch: Die Volumes wieder dem Cache zuordnen und mal über Nacht warten, damit sich der Cache wieder füllt.

Ergebnis: Nix, gleiches verhalten.

2. Versuch: Cache global deaktivieren und neu einrichten

Ergebnis: Da häng ich jetzt. Ohne Fortschritt seit gestern.

pasted-from-clipboard.png

Mein Verdacht ist folgender:

Ich glaube die GUI funktioniert hier nicht mehr. Denn wenn ich mir das Cachedevice mit dmsetup ansehe. Hat das meiner Meinung nach weder ein zu cachendes Device zu gewiesen UND es sind immer noch 1MB Blocksize konfiguriert. Ich hätte gestern eigentlich auf 2MB hochgedreht, als ich die zu cachenden Volumes wieder aktivieren wollte.

Ich würde ja jetzt mal noch etwas zusätzlich Daten sichern und die QNAP restarten. Bin hald mal gespannt, ob das Ding den Reboot überlebt.

Meiner Meinung nach dürfte nix passieren, denn ich glaube das CacheDevice ist mit keinem Datenvolume verbandelt. Bin aber nicht sattelfest genug mit dmsetup um mir sicher zu sein.

Hat da wer Erfahrung damit??

[~] # dmsetup status CG0ssddev -vvvv
Timestamp:       0.000000000 seconds
dm version   OF   [16384] (*1)
dm status CG0ssddev  OF   [16384] (*1)
Timestamp:       0.000630527 seconds
Name:              CG0ssddev
State:             ACTIVE
CG0ssddev (253:2): read ahead is 256
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 2
Number of targets: 1
UUID: uuid

0 191143936 flashcache_ssd CG0 enable WRITE_BACK 93184 38723 38723 54461 0
conf:
        capacity(93184M), associativity(512), data block size(1024K) metadata block size(4096b)
        forced_plugout 0 cached disk 2 stop_sync 0 suspend_flush 0
Slot Info:
        1 Used LVM-0v0xg6r05OB0yekrL88AcZWyZVIdA8KDqatvbJSdUbyuao2826TRQgs0c7W1uEYv
        2 Used LVM-803S8Av4DDABOuaNQTTEZ6ufmqIyt375a25umVt2BAzFVPpdUwJX771nqUPVBPcX
        10 Used j186A5-QF33-SwEP-3soh-JrdE-Br1p-tm5E5c
stats: 
        nr_queued(0) nr_jobs(1)
        lru hot blocks(62513), lru warm blocks(46590)
        lru promotions(115144), lru demotions(22436)

[~] # lvm lvdisplay vg256           
  --- Logical volume ---
  LV Path                /dev/vg256/lv256
  LV Name                lv256
  VG Name                vg256
  LV UUID                QrzWPa-nQaf-pn0L-XSQ5-jMWO-6mjo-Aeib4F
  LV Write Access        read/write
  LV Creation host, time HomeServer, 2021-05-26 15:20:40 +0200
  LV Status              available
  # open                 1
  LV Size                91.14 GiB
  Current LE             23333
  Segments               1
  Allocation             inherit
  Read ahead sectors     8192
  Block device           253:1

Also die SMART Werte schauen noch OK aus. Vom Wear Leveling bin ich da noch über ~70% auf beiden.

Ich glaube ja eher, dass durch ein Firmware Upgrade da irgendwas unbemerkt in die Binsen gegangen ist. Ich sehe auch im Ressource Monitor vom QTS, dass die beiden Devices rein gar nichts machen. Sprich keine IOPS. Wären die SSDs tot geschrieben wäre mMn das Fehlerbild ein anderes. zB.: auch niedrige IOPS aber horrend hohe Latenzen...

EDIT:

Auch die Grundlast ist jetzt auf dieser NAS im Homeserverbetrieb ist jetzt eher überschaubar hoch. Sollte jetzt auch nicht mehr sein als auf ner SSD wo Windows drauf läuft.

Kurzes Update von mir.

Reboot hat es wieder gerichtet. Hab allerdings zur Sicherheit noch mal nein großflächiges Extrabackup vorher gemacht. Ich hab ja langsam den Verdacht, dass der Plex Intro Scanner daran schuld ist. Jedes mal wenn der bei den geplanten Tasks läuft geht der RAM-Bedarf durch die Decke (trotz 16GB). Es lässt sich auch korrelieren. Immer wenn der Ram so bei knapp 100% ist, wird dann auch sukzessive der Cache-Hit immer schlechter und erholt sich auch nach dieser Lastspitze nicht mehr so richtig (bis zum nächsten Reboot). Hab das Feature von Plex jetzt wieder deaktiviert. Echt schade, dass die das immer noch nicht gefixt haben bei Plex.

Zusätzlich habe ich mir nun 2 1TB MX500er SSDs bestellt. Werde demnächst das QTS dort hin übersiedeln. Dann ist auch der Cache nicht mehr so bitte notwendig. Im aktuellen Ausbaustadium ist meine QNAP ohne diesen Cache im QTS-Desktop kaum bedienbar. Jede App startet gefühlt ewig und/oder inkomplett. Mit Cache ist das Ding wenigstens halbwegs bedienbar. Bin gespannt wie das dann performed, wenn wirklich alles Systemrelevante mal zu 100% auf Flash läuft.

Da gehts um diese Funktion hier ->

pasted-from-clipboard.png

Das führt dann zu diesem RAM-Spike ->

pasted-from-clipboard.png

Was dann zu diesem Cache-Verhalten hier führt. Der Cache-Hit fällt dann von Tag zu Tag, wo das läuft immer weiter nach unten, bis diese praktisch gar nicht mehr funktioniert.

pasted-from-clipboard.png

Nach dem Reboot passt dann wieder alles.

Ich hatte auch schon andere Site-Effects, dass zB.: meine InfluxDB viele Write-Anforderungen in diesem Zeitfenster nicht mehr verarbeiten konnte. Sprich da gibts dann Datenlöcher im Grafana.

Es wäre schön, wenn man die Parallelität für diesen Intro-Task einstellen könnte. Denn ich finds schon krasse, dass das mit 10GB RAM, der da geschluckt wird, immer noch nicht gescheit läuft.

Es ist ja ein schönes Feature, welches ich auch gerne verwenden würde. Aber wenn mir dann die halben anderen auf der NAS laufenden Services jedes mal abkrachen, kann ich das so nicht verwenden.

Gibt auch diverse Threads im Plex-Forum dazu. Plex will das aber scheinbar nicht so recht als Problem zu akzeptieren.

Hmm, seltsam.

Ja ich hab das bewusst, wenn schon nur als geplanter Task drinnen. Denn wenn ich den schon beim Hinzufügen rechnen lasse (was ich früher auch so eingestellt hatte) bricht mir sofort schon die Kopierperformance vom PC zum NAS komplett ein, weil die CPU-Last durch die Decke geht. Die A-CPU ist hald nur ca. halb so schnell, wie die aus dem D-Modell (und die ist schon keine Rakete). Daher verlagere ich das gerne in Tageszeiten, wo es mir egal ist, wenns grade etwas hängt.

Plex als App selbst ist bei mir auch schon auf SSD. Nur das System ist leider noch HDD + Cache. Soll sich aber diese Woche ändern, wenn alles gut geht. Hoffe ich bekomme das bestehende RAID wieder hinzugefügt, nach dem ich auf den neuen SSDs alles neu initialisiert habe.

Sollte nach dieser Doku hier ja eigentlich möglich sein.

https://www.qnap.com/en/how-to…attach-volumestorage-pool