HDD Verschlüsselung und Btrfs - tierfergehende technische Fragen

WilliTheSmith

Lt. Commander
Registriert
Dez. 2008
Beiträge
1.193
Hallo,

ich plane zur Zeit mein Eigenbau NAS auf 15TB und mehr Nutzlast zu vergrößern. In dem Zuge möchte ich dann auch die Daten-Platten verschlüsseln und in einem Raid 1 (über Btrfs) zusammenfassen. Erfahrungen mit Btrfs habe ich bereits viele auf der Arbeit und zu Hause machen dürfen, mit LUKS allerdings nicht, daher nun ein paar recht spezielle Fragen:

1. Wie viele Bytes müssen auf der HDD physikalisch geschrieben werden, wenn man 1kB Daten (einer 1GB großen Datei, falls es ein wichtiger Parameter ist) verändert? Werden es durch die Verschlüsselung bzw. des AES Betriebsmodi weitaus mehr (CBC beeinflusst bspw. doch alle folgenden Blöcke?) oder gibt es keinen allzu großen nennenswerten Unterschied?

2. Wie verhält sich das Dateisystem bei einem auf Hardwareebene gekippten Bit oder Unrecoverable Bit Error? Btrfs erkennt diese ohne Verschlüsselung einwandfrei und korrigiert diese. Funktioniert dies bei einer darunterliegenden Verschlüsselung ebenso problemlos? Gibt es hier Probleme, die auftreten können?


Ich würde mich freuen, wenn mir jemand meine Fragen beantworten könnte oder mich auf geeignete Dokumentation oder Tests verweisen könnte. Parallel werde ich das ganze System natürlich in einer VM testen und verinnerlichen.

Viele Grüße
 
Eine Anmerkung vorab: Ich hab sowohl schon öfters mit btrfs als auch mit LUKS gearbeitet, aber nie mit beiden gemeinsam. Meine Antworten beruhen daher eher aus theoretischen Überlegungen und weniger aus praktischen Erfahrungen damit.

WilliTheSmith schrieb:
1. Wie viele Bytes müssen auf der HDD physikalisch geschrieben werden, wenn man 1kB Daten (einer 1GB großen Datei, falls es ein wichtiger Parameter ist) verändert?
Ich schätze irgendwas zwischen 4 und 12kB. Die meisten aktuellen Festplatten haben 4kB-Sektoren, d.h. selbst wenn du nur 1 Bit ändern wolltest, müsste der ganzen 4kB-Sektor neu geschrieben werden. Sind die 1kB über zwei Sektoren verteilt müssen zwei Blöcke (8kB) neu geschrieben werden. Zusätzlich müssen vermutlich auch Metadaten geändert werden, was wiederum das Schreiben von min. einem weiteren Block erfordert. Das unterscheidet sich aber nicht vom unverschlüsselten Fall.

WilliTheSmith schrieb:
Werden es durch die Verschlüsselung bzw. des AES Betriebsmodi weitaus mehr (CBC beeinflusst bspw. doch alle folgenden Blöcke?) oder gibt es keinen allzu großen nennenswerten Unterschied?
Jeder Sektor wird einzeln verschlüsselt. Da jede Änderung eines Sektors sowieso das Neuschreiben desgleichen erfordert, ändert die Verschlüsselung die zu schreibende Datenmenge nicht.

WilliTheSmith schrieb:
2. Wie verhält sich das Dateisystem bei einem auf Hardwareebene gekippten Bit oder Unrecoverable Bit Error? Btrfs erkennt diese ohne Verschlüsselung einwandfrei und korrigiert diese. Funktioniert dies bei einer darunterliegenden Verschlüsselung ebenso problemlos? Gibt es hier Probleme, die auftreten können?
Das ist eine schwierige Frage. Ein Bitfehler der Festplatte hat zur Folge, dass der entsprechende Sektor nach der Entschlüsselung nur Datenmüll enthält. btrfs sollte aber mit RAID1 und data-checksums in der Lage sein diesen "kaputten" Sektor zu erkennen und zu reparieren.
 
Ich habe noch nicht mit btrfs gearbeitet aber ich kann Limit's Überlegungen soweit zustimmen.

Bei CBC sind die zusammenhängenden Blöcke auch nur einen Festplatten-Sektor (4KB) groß. Übrigens benutzt man bevorzugt nicht mehr CBC sondern den XTS mode bei Festplattenverschlüsselung, was bei LUKS aber glaube ich auch schon die Standardvorgabe ist.
 
Danke für eure Antworten, die haben mir schon einmal sehr weiter geholfen und bestätigen das, was ich in meiner letzten Recherche an Informationshäpchen gefunden habe.

Ich wusste nicht sicher, wie groß bei Festplatten-Verschlüsselung die verschlüsselten Sektoren sind. Aber wenn diese die gleiche Größe wie die Sektoren der HDD haben, ist das ganze ja nicht weiter tragisch.

Zu 2: Also eigentlich auch genauso wie bei Btrfs Raid 1 ohne Verschlüsselung: Das Dateisystem erkennt anhand der Checksum, dass ein Sektor fehlerhaft ist und korrigiert ihn mithilfe von Redundanzen. Obs nun nur ein fehlerhaftes Bit oder ein ganzer Sektor ist, sollte keinen Unterschied machen.


Dann kann ich mich ja dieses Wochenende mal dran machen und das ganze in einer VM testen.
 
WilliTheSmith schrieb:
Obs nun nur ein fehlerhaftes Bit oder ein ganzer Sektor ist, sollte keinen Unterschied machen.

Das kommt ganz darauf an wie die Fehlerkorrektur implementiert ist. Es gibt durchaus Fehlerkorrekturen die nur mit einzelnen fehlerhaften Bits klarkommen. Durch die AES-Entschlüsselung wird der ganze Sektor aber zu Pseudo-Zufallsdaten wenn nur ein Bit gekippt ist.
Ich würde aber davon ausgehen dass btrfs auch mit komplett fehlerhaften Sektoren umgehen kann. Schließlich kommt es bei Festplatten oft vor dass einer oder mehrere Sektoren gar nicht mehr funktionieren und dafür sollte btrfs ja auch gerüstet sein.
 
Ich bin mir zwar nicht ganz sicher, aber mWn kann btrfs die checksums nur dazu benutzen Fehler zu entdecken. Zum korrigieren braucht es auch bei nur einem einzelnen falschen Bit eine Kopie, entweder auf dem gleichen Laufwerk (dup) oder auf einem anderen (RAID1/10/5/6). Von daher macht es wohl keinen Unterschied ob ein Bit oder ein Sektor.
 
Zurück
Oben