Seite 1 von 1
ZFS Checksummen
Verfasst: 05.02.2021 18:49:09
von king-crash
Hallo,
bisher dachte ich ZFS würde die Checksummen beim Lesen der jeweiligen Datei überprüfen. Um das zu testen habe ich auf einer kleinen Partition einen Pool erstellt und eine Datei mit ca 90% Größe des verfügbaren Platzes erstellt. Dann mit "shasum" einen Hash davon ermittelt. Nun simuliere ich mittels schreibens genau eines Bytes in /dev/sd*? einen Fehler. "shasum" gibt mir jetzt einen abweichenden Hash während "zpool status" keine Probleme meldet. Erst wenn ich jetzt "zpool scrub" durchführe wird der Fehler bemerkt.
Kann ich ZFS irgendwie dazu bringen, die Checksummen bei jedem Lesevorgang zu überprüfen?
Hier die Vorgehensweise:
root@debiantest:~# zpool create -f -m /zfs-single zfs-single 1ddfc8d1-10ed-a643-a88d-c11f74b17483
root@debiantest:~# dd if=/dev/zero of=/zfs-single/testdatei bs=1M count=800
800+0 Datensätze ein
800+0 Datensätze aus
838860800 Bytes (839 MB, 800 MiB) kopiert, 9,86647 s, 85,0 MB/s
root@debiantest:~# shasum /zfs-single/testdatei
837b0910bd47c4dfb20d36b759beb4a73edc4a93 /zfs-single/testdatei
root@debiantest:~# ./disktest /dev/sda2 34 1000000003
vorher 00
root@debiantest:~# sync; echo 3 > /proc/sys/vm/drop_caches
root@debiantest:~# shasum /zfs-single/testdatei
2518c22cf9bd0785e752a7c0d1e534e790d29fdf /zfs-single/testdatei
root@debiantest:~# zpool status
pool: zfs-single
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
zfs-single ONLINE 0 0 0
1ddfc8d1-10ed-a643-a88d-c11f74b17483 ONLINE 0 0 0
errors: No known data errors
root@debiantest:~# zpool scrub zfs-single
root@debiantest:~# zpool status
pool: zfs-single
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see:
https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
scan: scrub repaired 0B in 00:00:03 with 1 errors on Fri Feb 5 18:12:20 2021
config:
NAME STATE READ WRITE CKSUM
zfs-single ONLINE 0 0 0
1ddfc8d1-10ed-a643-a88d-c11f74b17483 ONLINE 0 0 1
errors: 1 data errors, use '-v' for a list
Hier das Programm zur Bytemanipulation:
41255
Re: ZFS Checksummen
Verfasst: 06.02.2021 21:30:27
von bluestar
Ich hab mal zum besseren Verständnis deines Problems ein paar Fragen:
- Hast du vor der Manipulation geprüft, dass du wirklich in einen Datenblock einer Datei manipulierst und nicht im Metadatenbereich von ZFS?
- Ich würde auch gerne dein Problem mit den Checksummen einmal nachvollziehen können, welchen konkreten Problemfall versuchst du hier durch Tests nachzustellen?
Re: ZFS Checksummen
Verfasst: 07.02.2021 11:49:40
von king-crash
Mein Verständnis von ZFS war bisher, dass durch die Checksummen, die jeder Block hat, Fehler jedweder Art beim Lesen gefunden werden können.
Siehe Hierzu:
https://blogs.oracle.com/bonwick/zfs-en ... -integrity
The blocks of a ZFS storage pool form a Merkle tree in which each block validates all of its children.
Genau das wollte ich durch überschreiben eines zufälligen Bytes testen und es scheint nicht zu funktionieren.
Zu 1:
Ich habe das Dateisystem nur 1GB groß gemacht und zu 90% mit einer Datei gefüllt. Die Wahrscheinlichkeit die Daten zu treffen ist also hoch. Es muss aber auch egal sein, da Fehler sich nicht spezifisch die Nutzdaten suchen
Durch Checksummen auf Blockebene müsste ein Fehler, wenn er nicht gerade in einem unbenutzten Bereich ist, bemerkt werden.
Zu 2:
Der Fehler soll ein fehlerhaftes Byte von der Festplatte, sei es von der HDD selbst oder vom SATA, simulieren.
Re: ZFS Checksummen
Verfasst: 07.02.2021 12:30:28
von diggerchen
@king-crash: Hattest Du während der Ermittlung der falschen Prüfsumme Einträge im Log?
Re: ZFS Checksummen
Verfasst: 07.02.2021 12:50:12
von bluestar
Also gemäß der ZFS-Doku (
https://openzfs.github.io/openzfs-docs/ ... ksums.html) wird dein simulierter Fehler tatsächlich nur durch
erkannt.
Nach dem Scrub-Durchlauf müsstest du einen Lesefehler beim Zugriff auf die Datei bekommen.
Re: ZFS Checksummen
Verfasst: 07.02.2021 12:52:32
von king-crash
@diggerchen
Habe ich nicht nachgesehen, aber ich gehe davon aus dass wenn "zpool status" keine Fehler anzeigt, generell auch keine bemerkt wurden.
Ein nachfolgendes scrub hat die Fehler bemerkt. Aber nach allem was ich gelesen habe sollte es explizit nicht passieren, dass gelesene Daten fehlerhaft sind.
Re: ZFS Checksummen
Verfasst: 07.02.2021 12:56:23
von king-crash
@bluestar
detects data corruption upon reading from media
Liest sich für mich wie wenn Checksummen generell beim Lesen berechnet werden.
Scrub dient meines Verständnisses nach nur dazu wirklich alle Daten, nicht nur die die ohnehin gelesen werden, zu überprüfen.
Eventuell liege ich hier falsch, aber das ist doch wirklich eine herbe Einschränkung.
Re: ZFS Checksummen
Verfasst: 07.02.2021 20:14:43
von diggerchen
Ich habe das ganze mal etwas modifiziert nachgestellt. Einmal in Debian Buster und einmal in Ubuntu 20.10, jeweils als VirtualBox VM mit zusätzlicher kleiner Platte für den Pool, in der ich jeweils per Hexeditor ein Byte verändert habe. Der Hash der Testdatei weicht dabei in beiden Fällen nach der Änderung ab, jedoch meldet nur zpool in Ubuntu umgehend einen data error, während in Debian der Fehler erst bei einen Scrub auffällt.
Die Ubuntu-Variante wäre so, wie ich mir das vorstelle. Wie bekommt man das in Debian hin?
Re: ZFS Checksummen
Verfasst: 07.02.2021 22:24:53
von bluestar
Welche ZFS Versionen hast du denn unter Debian bzw. Ubuntu getestet?
Re: ZFS Checksummen
Verfasst: 07.02.2021 23:17:15
von diggerchen
0.8.6 aus den Backports mit Debian, 0.8.4 bei Ubuntu.
Re: ZFS Checksummen
Verfasst: 08.02.2021 09:56:40
von diggerchen
Da ich einmal zugange war habe ich das auch in FreeBSD 12.2 durchgespielt. Dort kann ich den zweiten Hash gar nicht berechnen und erhalte stattdessen einen I/O-Error. Zusammen mit Log-Einträgen und einem data error im zpool-Status. Lässt sich das Verhalten im Fehlerfall vielleicht innerhalb von ZFS konfigurieren?
Re: ZFS Checksummen
Verfasst: 08.02.2021 11:03:51
von king-crash
diggerchen hat geschrieben: 
08.02.2021 09:56:40
... erhalte stattdessen einen I/O-Error...
So hätte ich mir das auch vorgestellt. Der geiche Fehler tritt auch mit der Version 2.0.2 von dkms-zfs auf.
Edit: Version 0.7.12 hat das gleiche Problem.
Edit: Ubuntu Version 0.8.3 hat das Problem auch.
Re: ZFS Checksummen
Verfasst: 10.02.2021 12:57:12
von diggerchen
Ich glaube ich habe Deinen Bugreport gefunden
. Bin gespannt was dabei rauskommt.
Re: ZFS Checksummen
Verfasst: 10.02.2021 17:13:45
von king-crash
Entfernte Festplatten werden wohl auch erst nach einem Zugriff das Dateisystem bemerkt, obwohl das /dev/ Device wesentlich früher fehlt. Handelt es sich um ein Spare gibt es nie keine Meldung. Kann das jemand bestätigen?
Re: ZFS Checksummen
Verfasst: 10.02.2021 19:02:57
von diggerchen
Der Tipp Richtung shasum war nicht schlecht. Bei mir unterschlägt das Ding den Fehler und gibt 'nen kaputten Hash raus. Verwende ich für den Zugriff auf die Test-Datei sha512sum oder auch einfach cp, dann gibt's den gewünschten I/O-Error auch unter Debian mit 0.8.6. Allerdings "merkt" zpool von dem Fehler erst beim 2. Mal oder 3. Mal etwas. Das bleibt komisch.
Re: ZFS Checksummen
Verfasst: 11.02.2021 02:45:28
von king-crash
Ich habe mal den Ablauf gescripted:
41264
Es ist wirklich komisch. Nachdem dd ausgeführt wurde wird der Fehler erkannt. Was genau passiert da in shasum anders?
Wenn ich eine Datei als Device verwende gibt es das Problem auch nicht...
Re: ZFS Checksummen
Verfasst: 11.02.2021 09:40:55
von diggerchen
Mir ist lediglich aufgefallen, dass shasum ein Perl Script ist. sha512sum und cp nicht. Vielleicht kommt der Fehler in der Perl Fehlerbehandlung nicht an oder wird nicht ausgewertet? Ich kenne mich mit Perl aber auch nicht aus um das beurteilen zu können.
Re: ZFS Checksummen
Verfasst: 11.02.2021 11:57:01
von bluestar
Ich vermute das Problem hängt damit zusammen, das
shasum als default im Text-Modus arbeitet und nicht im Binär-Modus. Versuch mal
shasum -b DATEI.
https://manpages.debian.org/buster/perl ... .1.en.html
Re: ZFS Checksummen
Verfasst: 11.02.2021 12:18:31
von king-crash
Binär oder Textmodus machen nur unter Windows einen unterschied (\r\n). Ich bin ziemlich sicher, dass shasum auch ein Problem hat. Aber wenn es genau dann einen falschen Hash meldet wenn im Dateisystem auch etwas nicht stimmt und dies das nicht anzeigt ist mit Sicherheit auch im zfs etwas faul. Zumal nach wiederholtem Starten von shasum zfs den Fehler irgendwann doch bemerkt. shasum werde ich aber auch noch untersuchen.
Für das Skript habe ich mal ein github repo erstellt:
https://github.com/Hi8chee7/zfstest.
Re: ZFS Checksummen
Verfasst: 11.02.2021 14:38:19
von mludwig
Vielleicht ein Problem durch den Cache? Du legst im ZFS eine Datei an, und modifizierst dann am Dateisystem vorbei den darunter liegenden Datenträger. Wenn die Datei noch von ZFS oder dem Betriebssystem im Cache gehalten wird, fällt die Modifikation erst auf wenn wirklich vom Datenträger gelesen werden muss. Der Cache ist ja noch korrekt. Vielleicht zwischendurch mal neu starten ...
Re: ZFS Checksummen
Verfasst: 11.02.2021 15:33:25
von king-crash
Dann dürfte der zweite Aufruf von shasum keinen abweichenden Hash liefern.
Re: ZFS Checksummen
Verfasst: 12.02.2021 11:52:10
von king-crash
Also die bisherigen Erkenntnisse sind, dass shasum einen read error ignoriert und zfs unter gewissen Umständen Fehler nicht weitermeldet.
Hier ist der Thread auf Github:
https://github.com/openzfs/zfs/issues/11589