nikeee

Aktuell lasse ich wieder einen Parity-Check laufen. Dieses mal aber im Maintenance-Mode, bei dem die Dateisysteme nicht gemountet sind. Ich hab mit dmesg -w mal im Kernel-Log geschaut und sehe auch hier die bereits gefundenen 23 Korrekturen in dieser Form: [122588.979543] md: recovery thread: P corrected, sector=8358852832 [122588.979552] md: recovery thread: P corrected, sector=8358852840 [122588.979557] md: recovery thread: P corrected, sector=8358852856 Mit dem Sektor und der Blockgröße kann man das Byte-Offset berechnen (Blockgröße ist 512 bei mir): byte_offset = sektor * block_size Man bekommt den Block im Dateisystem dann so: fs_block = byte_offset / <filesystem_blocksize> Dann kann man mit xfs_db weiter arbieten. Das Problem ist, dass das Dateisystem bei mir mit LUKS verschlüsselt ist. Da die Parität quasi auf Device-Ebene gemanaged ist, komm ich zwar an das kaputte byte, aber weil noch ne Verschlüsselung darüber liegt, nicht direkt an die betroffene Datei. Das würde aber auch dazu führen, dass ein kaputtes byte dann auch direkt den Ganzen Crypto-Block kaputt macht. Je nachdem, was mein XFS da nutzt, sind das dann mindestens 32 byte. Das kann schon ärgerlich werden. Ich werde das also wohl so akzeptieren müssen. Weiter habe ich noch ein bisschen analysiert und mit dem Skript einmal die wichtigen SMART-Werte for disk in /dev/sd?; do echo "=== $disk ===" smartctl -a $disk | egrep "Reallocated_Sector_Ct|Reported_Uncorrect|Command_Timeout|Current_Pending_Sector|Offline_Uncorrectable|UDMA_CRC_Error_Count" echo done Dort habe ich diese Ausgabe bekommen: /dev/sdh sticht da bei UDMA_CRC_Error_Count heraus, also crc-fehler bei Übertragung. Ich werd das Kabel davon nochmal überprüfen und gucken. Mehr kann ich da glaub ich auch nicht tun. Ich habe mir die betroffenen Sektoren notiert und werde mal schauen, ob die bei einem erneuten Check deckungsgleich sind. Danke für deine Hilfe.

Na das ist doch genau das, was ich gesucht habe. Dann muss ich halt nur 1x auf 8 Platten gucken, was in dem Sektor liegt. Ich werde das mal probieren.

Ich hätte hier vermutet, dass eine Platte irgendwelche Probleme hat und deshalb die Parität nicht stimmt. Oder auch ein lockeres SATA-Kabel. Der erste war nur lesend (weil das ja der default nach einem unexpected shutdown war) und die anderen schreibend. Ich _vermute_ dass er beim 3. Lauf unterschiedliche Fehler geinden hat, aber ich weiß es natürlich nicht. Geht das nicht irgendwie anders? Würde ungern checksummen von 90TB von hand berechnen. Kann man da dem Parity-Check nicht sagen, dass er loggen soll, an welchen Offsets oder inodes die Paritätsprobleme waren? Dann müsste ich nur 8 Dateien anschauen. Wie finde ich raus, warum das scheinbar der Fall ist?

Hi, ich hatte einen Server-Crash, bei dem sich das Mainboard verabschiedet hat. Daraufhin habe ich das Mainboard durch ein neues getauscht (und dabei gleichzeitig den RAM geupgraded). Nach dem ersten Startlief das NAS und hat auch einen Partiy-Check im Lesemodus gestartet (hier sichtbar mit den 22 Errors): Daraufhin hab ich einen Check im Schreibemodus laufen lasen. Der hat dann das 3-Fache gefunden und hoffentlich auch korrigiert. Nach dem Vorfall wollte ich eine 2. Parity-Platte in das Array einfügen (und das Array davor um eine andere Datenplatte verkleinern). Das würde ich alles aber ungerne machen, wenn ich noch Parity-Errors habe. Deshalb habe ich den 3. Check gestartet, der immer noch etwas gefunden hat. Diesen habe ich dann erstmal abgebrochen. Ich habe 8 HDDs im Array, 1 davon für Parity. In den SMART-History-Logs meiner Platten gibt es eine einzige mit diesem Eintrag: ATA Error Count: 1 CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 1 occurred at disk power-on lifetime: 192 hours (8 days + 0 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 58 a7 44 df 40 Error: ICRC, ABRT 88 sectors at LBA = 0x00df44a7 = 14632103 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 35 00 38 c8 40 df 40 00 14:53:51.469 WRITE DMA EXT 25 00 40 00 2a 40 40 00 14:53:51.439 READ DMA EXT 35 00 28 a0 3c df 40 00 14:53:51.438 WRITE DMA EXT 25 00 00 e8 57 33 40 00 14:53:51.427 READ DMA EXT 35 00 00 a0 34 df 40 00 14:53:51.417 WRITE DMA EXT Smart-Self-Tests lieferten auch keine Ergebnisse. Meine Fragen: Wie finde ich raus, welche Platte ein Problem hat? Woran kann es noch liegen, dass die Fehler scheinbar nicht verschwinden oder wieder neue entstehen? Sind meine Daten noch sicher?

Any chance to add rmlint? Links: - https://github.com/sahib/rmlint - https://rmlint.readthedocs.io

Ja, ziemlich genau das wäre mein Backup-Plan gewesen. Sicher, dass es bei dem von dir verlinkten Artikel nicht um clientseitiges Caching vom sshfs geht? Bin zwar nicht so ein Fan von FUSE, aber zur Not gibt's sicher auch irgendein random FUSE-File-System, das genau das macht. Damit kann man dann transparent zu der eigentlichen Anwendung cachen. Edit: Gerade gefunden: Es gibt auch 2 richtige Kernelmodule, die sowas können: BCache und fscache, beide sind Teil von Linux. Bei dem ranzigen Fuse-FS von oben sind auch noch 5 andere verlinkt, die man probieren kann. /Edit Genau solche Lösungen wollte ich eigentlich vermeiten, da ich möglichst stets auf von Haus aus unterstützte Funktionen setzen will, allein aus Wartungsgründen. Deshalb würde ich auch den Write-Cache von Unraid verwenden, statt selbst irgendwas zu basteln. Da Read-Caches wohl ein Feature ist, was man von einer NAS-Firmware erwarten könnte, habe ich einfach mal nachgefragt. Synology war buchstäblich das erste Google-Suchergebnis von "nas ssd read cache", womit ich validiert hab, ob das ein Feature ist, das bei NAS erwartbar ist (hat nichts speziell mit dieser Firma zu tun, wollte es nur als Beispiel verlinken). Mir ist selbstverständlich bewusst, was das für eine Auswirkung auf die SSDs haben wird. Cache-Invalidation ist eines der "schwierigen" Probleme in der informatik. Da ich mit der reduzierten Laufzeit leben kann (ja, kann ich wirklich), wäre es mir egal, ob der Cache irgendwas fancyges wie FP-Growth-Analyse, einen LSM-Tree oder eine simple Cache-Eviction-Strategy der dutzenden existierenden verwendet (für mich würde auch ein simpler LRU-Cache mit Mindesthaltedauer reichen; in meinem Fall im Speziellen verändern sich die Daten auch nicht, das würde es noch deutlich vereinfachen). Sowas muss man im Jahr 2021 auch eigentlich nicht mehr selbst implementieren. Hat sich dahingehend aber wohl erledigt. Viele Grüße

Meine initiale Frage zielte explizit auf einen SSD-Schreibcache aus, nicht auf den RAM (die Möglichkeit habe ich selber später auch noch eingeworfen). Ich hab 3 Fragen gehabt, von denen wurden 2.5 beantwortet und wollte die Sache abschließen. Damit man nicht großartig suchen muss, hab ich kurze Antworten dazugeschrieben und noch ein paar Pointer zu StackExchange da gelassen. Wenn etwas technisch an meiner Zusammenfassung nicht stimmt, korrigiere mich gerne. @mgutt sehr guter Hinweis, danke! Ich werd mal schauen, ob das funktionieren wird. SMB werde ich bei dem Use-Case nicht einsetzen (eher (S)FTP und HTTP). Daher wird's vielleicht auch ein simpler Webserver mit aggressivem Caching. Das hatte ich nicht vor, deshalb hab ich hier gefragt. Keine Ahnung, wieso diese Aussage für diesen Thread relevant ist...? Schaltet mal ein Trigger-Level runter. Ich hatte ein Problem, hab den Use-Case dargestellt und wir haben gemeinsam Lösungen im Rahmen der Unraid-Plattform erarbeitet. Nicht mehr, nicht weniger. Viele Grüße

Da unraid kein HW-Raid verwendet und Wissen über das konkrete Dateisystem hat, könnte es ja davon gebrauch machen und nicht nur Blöcke, sondern auf eine intelligentere Art Daten in den Cache schieben (z. B. über Zugriffsmuster oder durch Kopieren der gesamten Datei; wäre letztendlich nur ein Implementierungsdetail). Mir ist bewusst, wie ein Lese-Cache funktioniert. Ich fasse mal meine bisherigen Antworten aus dem EIngangspost für die Nachwelt zusammen, als tl;dr: Unterstützt unRAID einen Lese-Cache? Nein. Gibt's Alternativen, um das trotzdem in unRAID hinzubekommen? Nicht built-in. Ist Anwendungs- und OS-spezifisch. Ggf. einen Reverse-Proxy davorschalten, der das Caching zur Not selber managed (siehe Post von @Ford Prefect). Würde ggf. implizieren, dass man nicht die built-in-Services von Unraid zum Servieren nutzen kann. Man kann ein bisschen am File-Caching mit hdparm rumschrauben eventuell sogar mit noatime mounten. "Linux will cache as much disk IO in memory as it can."; Sehr waage Formulierung; ggf. gibt es über hdparm hinaus noch weitere Kernel-Settings dafür Ist es geplant? Offenbar nicht. Vielen Dank!

Ich verstehe die Frage nicht. Caches sind nicht notwendigerweise so groß wie das Medium, wo die Daten liegen. Z. B. Synology unterstützt Lese-Caches, die haben aber auch einen richtigen RAID-Controller. Das Prinzip ansich sollte aber nicht beschränkt auf HW-Unterstützung sein. Welche Eviction-Strategie unterstützt wird, ist mir im Prinzip egal. Also kann ich davon ausgehen, dass unRAID einen Lese-Cache nicht untersützt und auch nicht unterstützen wird?

Konkrete Geschwindigkeiten kann ich gerade nicht benennen. Was ich vorhabe, ist eine (S)FTP-Freigabe, über die mehrere Millionen kleine Dateien (ca. 0-100MB) über eine 10Gibit-Leitung serviert werden sollen. Habe keinen Zugriff auf die Konfiguration der Switche. Die Dateien sind größentechnisch zu viel, um in den SSD-Schreibcache zu passen. Die Abfragereihenfolge der Dateien kann ich nicht kontrollieren. Ich denke, ein LRU-Cache wäre ausreichend. Generell wäre es gut, wenn die Netzwerkkarte das Bottleneck wäre. Meine Befürchtung ist (getestet habe ich es nicht, Erfahrung habe ich auch nicht), dass durch die vielen kleinen Dateien die Bandbreite auf den HDDs extrem runter gehen könnte. Grundsätzlich würde ich es auch ohne Read-Cache versuchen wollen, aber es wäre gut, wenn es die Option gäbe. Kann man den RAM als Read-Cache verwenden? Oder braucht ein Read-Cache (egal ob im RAM oder auf einer SSD) grundsätzlich einenen HW-RAID-Controller (, welcher von unRAID nicht unterstützt würde)?

Unterstützt unRAID einen Lese-Cache? Gibt's Alternativen, um das trotzdem in unRAID hinzubekommen? Ist es geplant?