Hallo! Ich habe eine große Serverfestplatte für den Einsatz im Desktop gekauft. So weit ich mich erinnere sind diese für den RAID-Einsatz konzipiert und haben daher eine andere / keine interne Fehlerbehandlung. Daher habe ich die Idee das "fehlerheilende" btrfs zu nutzen. Ist das sinnvoll oder Quatsch, weil es um eine andere Ebene der Fehler geht? Kann man bei btrfs verhindern, dass etwa balance automatisch regelmäßig läuft und die CPU lahmlegt? Danke für Hinweise. Viele Grüße Oskar
On Mon, 23 Jan 2023 17:20:03 +0100 tux-online <tux-online@web.de> wrote:
Ich habe eine große Serverfestplatte für den Einsatz im Desktop gekauft. So weit ich mich erinnere sind diese für den RAID-Einsatz konzipiert und haben daher eine andere / keine interne Fehlerbehandlung.
Zu btrfs möchte ich nichts sagen, aber die Fähigkeit, defekte Blöcke zu ersetzen, solange genügend funktionsfähige vorhanden sind, gilt für alle (aktuellen) Festplatten. Das Ersetzen von defekten Blöcken passiert jedoch nur beim Schreiben. Bei Blöcken, die beim Lesen Fehler melden, braucht man also einen Mechanismus, der diese mit korrigierten Daten aus gespeicherten Checksummen oder andere Redundanzen überschreibt. Von außen sieht das so aus, als ob dieselben Blöcke überschrieben würden, aber intern wird dort ein neuer Block "gemappt". Das passiert typischerweise beim scrubbing, das man hin und wieder durchführen sollte. Unterschiede existieren z.B. in der zu erwartenden Laufzeit, Lautstärke und Stromverbrauch. Diese Parameter lassen eine Festplatte für Desktop- oder Serverbetrieb geeigneter erscheinen, aber um die Abwägung kommt man nicht herum. Hinsichtlich der Blockfehlerkorrektur gibt es dagegen keine Unterschiede. Gruß, Tobias.
Am Dienstag, 24. Januar 2023, 02:31:39 CET schrieb Tobias Crefeld:
On Mon, 23 Jan 2023 17:20:03 +0100 tux-online <tux-online@web.de> wrote:
Ich habe eine große Serverfestplatte für den Einsatz im Desktop gekauft. So weit ich mich erinnere sind diese für den RAID-Einsatz konzipiert und haben daher eine andere / keine interne Fehlerbehandlung.
Zu btrfs möchte ich nichts sagen, aber die Fähigkeit, defekte Blöcke zu ersetzen, solange genügend funktionsfähige vorhanden sind, gilt für alle (aktuellen) Festplatten. Das Ersetzen von defekten Blöcken passiert jedoch nur beim Schreiben. Bei Blöcken, die beim Lesen Fehler melden, braucht man also einen Mechanismus, der diese mit korrigierten Daten aus gespeicherten Checksummen oder andere Redundanzen überschreibt. Von außen sieht das so aus, als ob dieselben Blöcke überschrieben würden, aber intern wird dort ein neuer Block "gemappt". Das passiert typischerweise beim scrubbing, das man hin und wieder durchführen sollte.
Unterschiede existieren z.B. in der zu erwartenden Laufzeit, Lautstärke und Stromverbrauch. Diese Parameter lassen eine Festplatte für Desktop- oder Serverbetrieb geeigneter erscheinen, aber um die Abwägung kommt man nicht herum. Hinsichtlich der Blockfehlerkorrektur gibt es dagegen keine Unterschiede.
Gruß, Tobias.
Hallo Tobias! Vielen Dank! Ich habe mich übrigens gegen btrfs und für xfs entschieden. Viele Grüße Oskar
On Wed, 25 Jan 2023 11:17:19 +0100 tux-online <tux-online@web.de> wrote:
Vielen Dank! Ich habe mich übrigens gegen btrfs und für xfs entschieden.
Mein Eindruck ist dass xfs ein Journaling-Dateisystem ist, das im Gegensatz zu ext4fs insbesondere für große Dateisysteme geeignet ist. Sieht man allein schon an der Dauer eines mkfs. Nachteilig gegenüber ext4fs ist, dass man es nicht mehr verkĺeinern kann. Ebenso wie ext4fs kann es Blockfehler nicht "reparieren". Bei großen Dateisystemen setze ich mittlerweile gerne auf zfs. Die Blockreparaturfähigkeiten entsprechen wohl btrfs. Je nach Plattengröße dauert ein Scrubbing Stunden bis Tage, aber währenddessen kann man auf dem Storage ganz normal weiterarbeiten. ZFS erfordert bei etlichen Linux-OS noch Nacharbeit über zusätzliche Repositories, etc. - wird also häufig nicht initial ab Installationsmedium unterstützt, aber das ändert sich grad. Hat im Gegensatz zu den BSDs (und natürlich Solaris) lange Zeit ein Mauerblümchen-Dasein in der Linux-Welt gefristet (Thema Stabilität), aber mittlerweile ist es recht robust und für Produktion gut geeignet. Vorteil ist die leichte Konfigurier- und Erweiterbarkeit sowie die gute Eignung für große Storages. Gut funktionieren auch Snapshots. Nachteil ist, dass man zfs-formatierte Partitionen wie xfs nicht mehr verkleinern kann. IIRC gilt das für mit zfs erstellte Pools Volumes genauso. Da sind md-RAIDs und LVM2 mittlerweile flexibler - wenn man es denn braucht. Gruß, Tobias.
Bei großen Dateisystemen setze ich mittlerweile gerne auf zfs. Die Blockreparaturfähigkeiten entsprechen wohl btrfs. Je nach Plattengröße dauert ein Scrubbing Stunden bis Tage, aber währenddessen kann man auf dem Storage ganz normal weiterarbeiten. ZFS erfordert bei etlichen Linux-OS noch Nacharbeit über zusätzliche Repositories, etc. - wird also häufig nicht initial ab Installationsmedium unterstützt, aber das ändert sich grad.
Gruß, Tobias.
Hallo Tobias! Das Reparieren von Blockfehlern hat mir bei Btrfs gefallen. Leider habe ich nicht direkt gefunden wie man srub / balance steuern kann. Btrfs hat mein System wohl damit immer wieder mal für einige Minuten fast unbrauchbar gemacht. Gegen ZFS spricht für mich, dass es nicht direkt ohne weitere Pakete unterstützt wird. Damit kann ich etwa mit Bootmedien bei Hardwarefehlern nicht ohne Probleme an meine Daten kommen. Zudem hat ja Btrfs viele Gemeinsamkeiten mit Zfs. Viele Grüße Oskar
participants (2)
-
Tobias Crefeld -
tux-online