staging.inyokaproject.org

Ich habe massive IO Probleme mit SMR Festplatten, Hardwareproblem kann ausgeschlossen werden, es tritt auf mehreren Baugleichen Servern auf und nur in Verbindung mit den Platten (auf den ebenfalls verbauten SSDs gibt es keine Probleme)

Seagate Guardian BarraCuda ST4000LM024 - Festplatte - 4 TB - intern - 2.5"

Ich bekomme einen solch hohen IO Load dass das ganze System stockt, dabei ist es egal ob die Platte allein drin hängt oder als raid.

Dürfte nicht damit zusammenhängen, aber genutzt wird die Platte als SR in einer XCP-NG VM. Ich vermute dass das Problem vor allen bei schreiboperationen mit kleinen Dateien (inkrementelle Backups) auftritt.

Kennt jemand das Problem?

SMR funktioniert am besten, wenn du große Dateien am Stück schreibst und dann hauptsächlich davon liest, weil für kleine Dateien ein Overhead dadurch entsteht, dass die benachbarte Spur erneut beschrieben werden muss - eine etwas ausführlichere Erklärung gibt es z.B. hier: https://www.hardwareluxx.de/index.php/artikel/hardware/storage/51244-cmr-smr-der-hdd-guide-zu-den-verschiedenen-aufnahmemethoden.html

ja, leider gibt es aber 4TB Platten in 2,5" nur als SMR. Aber ist es wirklich so arg dass das System quasi komplett blockiert?

Stell dir vor die Festplatte soll Daten auf die innerste Spur einer Scheibe schreiben, womit sie die Nachbarspur beeinflussen würde - dann muss sie auch die Nachbarspur neu schreiben und deren Nachbarspur usw. - d.h. mit einer kleinen Änderung an der falschen Stelle musst du im dümmsten Fall warten, bis die Platte einmal alle Spuren auf einer Scheibe neu geschrieben hat. Und wenn du das jetzt ständig wiederholst und Anwendungen auf I/O Operationen warten müssen (die wenigsten Programme unter Linux machen das asynchron und gerade bei einem Backup-Programm gibt es wenig sinnvolles, was das machen kann, während es auf I/O wartet), dann kann man damit prima ein System in die Knie zwingen.

Mit Zoned Storage kann man den Effekt abmildern, indem man Spursequenzen definiert, die nur sequentiell beschrieben werden und am Ende etwas Platz lassen, damit es am Ende der Sequenz keine Nachbarspur gibt, die neu geschrieben werden muss - das ist aber auf bestimmte Dateisysteme beschränkt und je nach Anwendungsfall nicht immer praktikabel: https://zonedstorage.io/

Wenn es unbedingt der Formfaktor sein muss (Miniaturisierung ist bei Servern nicht unbedingt die beste Idee), könnte man eine SSD nehmen - die kosten mehr, aber dafür kommen die mit vielen kleinen Schreiboperationen deutlich besser zurecht.

Wird vermutlich drauf rauslaufen dass ich nochmal in neue Platten investiere, da die HDDs hauptsächlich für Backups genutzt werden sollen habe ich mir keine Gedanken gemacht was die performance angeht... mit so etwas hätte ich nur natürlich gar nicht gerechnet.

Für Backups im Sinne von ich schreibe da mal was großes wie ein komplettes Abbild oder zumindest größere Stücke (wie z.B. (inkrementelle) Snapshots bei BTRFS), sollte das kein Problem sein. Nur wenn man das für viele kleine Schreiboperationen auf Dateiebene braucht (wie es z.B. rsync macht), kann das problematisch werden - Backup ist halt nicht gleich Backup.

und genau hier ist das Problem, ich habe bis jetzt BackupPC gesetzt welches auf rsync aufbaut. Das lief bis jetzt äußerst zuverlässig, aber in der Kombination macht es jetzt leider massiv Probleme weil mehrere rsyncs von verschiedenen Servern mit entsprechenden schreibzugriffen wohl tödlich für SMR platten sind. Bleibt mir also nur die platten zu wechseln oder das Backupsystem. XOA macht mit dem deltabackup ja scheinbar ein inkrementelles Backup, jedoch scheint es speicherintensiver zu sein und auch die GUI ist für den restore einzelner Dateien nicht so komfortabel. Ich muss mich wohl aber noch genauer damit auseinander setzen.