Könnte dies der gleiche Fehler wie https://github.com/zfsonlinux/zfs/issues/4050 sein? IIRC 6.5.3 war betroffen und Sie scheinen die hole_birth Funktion aktiviert zu haben, und das Problem scheint sich auf die gleiche Weise zu manifestieren: Datenblöcke am Ende der Datei, die stattdessen mit anderen Daten aufgefüllt werden sollten .

Wie auch immer, all diese "_ZFS send/recv Corrupts data_"-Fehlerberichte sind wirklich beängstigend, wenn man bedenkt, dass es sich um eine ZFS-Funktion handelt, die hauptsächlich für Replikate/Backups verwendet wird.

Danke für den Vorschlag @loli10K , es würde mir nicht
Ich habe die Ausgabe von Befehlen überprüft, die von @bprotopopov am 3. Dezember 2015 vorgeschlagen wurden
und es scheint, dass das System von Bug #4050 betroffen ist.

# zfs create -o recordsize=4k nas1FS/test_fs

# zfs set compression=on nas1FS/test_fs

# truncate -s 1G /nas1FS/test_fs/large_file

# ls /nas1FS/test_fs/large_file -als
1 -rw-r--r-- 1 root root 1073741824 Jun 28 16:25 /nas1FS/test_fs/large_file

# dd if=/dev/urandom of=/nas1FS/test_fs/large_file bs=4k count=$((3*128)) seek=$((1*128))             
384+0 records in
384+0 records out
1572864 bytes (1.6 MB) copied, 0.588248 s, 2.7 MB/s

# zfs snapshot nas1FS/test_fs<strong i="10">@20160628_1</strong>

# truncate -s $((2*128*4*1024)) /nas1FS/test_fs/large_file

# dd if=/dev/urandom of=/nas1FS/test_fs/large_file bs=4k count=128 seek=$((3*128)) conv=notrunc
128+0 records in
128+0 records out
524288 bytes (524 kB) copied, 0.224695 s, 2.3 MB/s

# dd if=/dev/urandom of=/nas1FS/test_fs/large_file bs=4k count=10 seek=$((2*128)) conv=notrunc
10+0 records in
10+0 records out
40960 bytes (41 kB) copied, 0.0144285 s, 2.8 MB/s

# zfs snapshot nas1FS/test_fs<strong i="11">@20160628_2</strong>

# zfs send nas1FS/test_fs<strong i="12">@20160628_1</strong> |zfs recv backup_raidz_test/test_fs_copy

# zfs send -i nas1FS/test_fs<strong i="13">@20160628_1</strong> nas1FS/test_fs<strong i="14">@20160628_2</strong> |zfs recv backup_raidz_test/test_fs_copy

# ls -als /nas1FS/test_fs/large_file /backup_raidz_test/test_fs_copy/large_file 
1593 -rw-r--r-- 1 root root 2097152 Jun 28 16:33 /backup_raidz_test/test_fs_copy/large_file
2223 -rw-r--r-- 1 root root 2097152 Jun 28 16:33 /nas1FS/test_fs/large_file

# md5sum /nas1FS/test_fs/large_file /backup_raidz_test/test_fs_copy/large_file 
2b1b5792f6a45d45a5399ff977ca6fda  /nas1FS/test_fs/large_file
7a8008b4cc398a0a4ad8a6c686aa0f6f  /backup_raidz_test/test_fs_copy/large_file

# md5sum /nas1FS/test_fs/.zfs/snapshot/20160628_1/large_file /nas1FS/test_fs/.zfs/snapshot/20160628_2/large_file /nas1FS/test_fs/large_file /backup_raidz_test/test_fs_copy/.zfs/snapshot/20160628_1/large_file /backup_raidz_test/test_fs_copy/.zfs/snapshot/20160628_2/large_file /backup_raidz_test/test_fs_copy/large_file
0f41e9d5956532d434572b6f06d7b082  /nas1FS/test_fs/.zfs/snapshot/20160628_1/large_file
2b1b5792f6a45d45a5399ff977ca6fda  /nas1FS/test_fs/.zfs/snapshot/20160628_2/large_file
2b1b5792f6a45d45a5399ff977ca6fda  /nas1FS/test_fs/large_file
0f41e9d5956532d434572b6f06d7b082  /backup_raidz_test/test_fs_copy/.zfs/snapshot/20160628_1/large_file
7a8008b4cc398a0a4ad8a6c686aa0f6f  /backup_raidz_test/test_fs_copy/.zfs/snapshot/20160628_2/large_file
7a8008b4cc398a0a4ad8a6c686aa0f6f  /backup_raidz_test/test_fs_copy/large_file

Ich bin mir nicht sicher, aber um das gleiche Problem beim "nas1FS" auszulösen, muss ich die Datei nicht ändern?
Wenn ich mich richtig erinnere, wurde die Datei nie geändert und existierte nicht im Snapshot "nas1FS/ backup@20151121_1 " und wurde nur kurz vor dem Snapshot "nas1FS/ backup@20151124 " zu fs hinzugefügt.
Glauben Sie, dass ein Upgrade auf v0.6.5.7 von spl/zfs dies beheben würde und keine negativen Auswirkungen auf den Quellpool hat?

Ich habe keine Einwände gegen ein komplettes Upgrade auf 0.6.5.7.
Leider habe ich einfach nicht genug Wissen über die Interna von zfs.
Ich war nur neugierig, ob ein Upgrade die Diagnose erschweren oder den Quellpool in irgendeiner Weise schädigen kann.

Ich konnte das System zum Absturz bringen, als ich eine md5-Summe der problematischen Datei auf einem Snapshot erstellte, wenn sie nicht im Quellpool vorhanden war ("nas1FS/backup@20151121_1"), also dachte ich, dass es auch ein Problem mit dem geben kann Quellpool.
Wären weitere Tests vor dem Upgrade sinnvoll (ich kann vor dem Upgrade keine Sicherungskopie der Datenträger mit dem Problem erstellen)?

Sie sollten wahrscheinlich versuchen, die Sperre/den Absturz auf 0.6.5.7 und/oder master zu replizieren und dies dann als eindeutiges Problem zu melden, wenn es weiterhin besteht.

Vorausgesetzt, es handelt sich um Bug #4050, manifestiert sich der Bug nur im Stream, wenn Sie per inkrementellem Senden übertragen, sodass die Daten des Quellpools nicht betroffen sind und ein Upgrade Ihrer ZoL-Version sicher sein sollte.

@loli10K danke für den Hinweis auf #4050. Und ich stimme voll und ganz zu, solche Probleme dürfen nicht vorkommen und wir sollten daran arbeiten, unsere Testabdeckung zu erhöhen, um sie zu verhindern.

@pwolny Ich würde auch empfehlen, auf 0.6.5.7 zu aktualisieren und zu überprüfen, ob Sie das Problem nicht mehr reproduzieren können.

Danke, ich werde auf 0.6.5.7 upgraden und es heute Abend oder morgen testen.

Ich habe auf v0.6.5.7 aktualisiert und das Problem wird interessanter.
Der Absturz beim Zugriff auf nicht vorhandene Datei im Snapshot tritt nicht mehr auf.
Das Senden/Empfangen von nas1FS/backup (enthält problematische Datei) ergibt auf Empfangs- und Sendeseite die gleichen md5-Summen (im Vergleich aller Dateien auf "nas1FS/backup" und "backup_raidz_test/backup").
Als ich am 3. Dezember 2015 (mit aktualisiertem spl/zfs) die von bprotopopov vorgeschlagenen Befehle wiederholt habe, habe ich die gleichen Prüfsummen für Quell- ("nas1FS/test_fs_A") und Ziel-FS ("backup_raidz_test/test_fs_copy_A") erhalten:

# cat zfs_hole_transmit_test.sh 
#!/bin/bash

date_today="20160701"
echo $date_today

zfs create -o recordsize=4k nas1FS/test_fs_A
zfs set compression=on nas1FS/test_fs_A
truncate -s 1G /nas1FS/test_fs_A/large_file
ls /nas1FS/test_fs_A/large_file -als
dd if=/dev/urandom of=/nas1FS/test_fs_A/large_file bs=4k count=$((3*128)) seek=$((1*128))
zfs snapshot nas1FS/test_fs_A@$date_today"_1"
truncate -s $((2*128*4*1024)) /nas1FS/test_fs_A/large_file
dd if=/dev/urandom of=/nas1FS/test_fs_A/large_file bs=4k count=128 seek=$((3*128)) conv=notrunc
dd if=/dev/urandom of=/nas1FS/test_fs_A/large_file bs=4k count=10 seek=$((2*128)) conv=notrunc
zfs snapshot nas1FS/test_fs_A@$date_today"_2"
zfs send nas1FS/test_fs_A@$date_today"_1" |zfs recv backup_raidz_test/test_fs_copy_A
zfs send -i nas1FS/test_fs_A@$date_today"_1" nas1FS/test_fs_A@$date_today"_2" |zfs recv backup_raidz_test/test_fs_copy_A

ls -als /nas1FS/test_fs_A/large_file /backup_raidz_test/test_fs_copy_A/large_file 

md5sum /nas1FS/test_fs_A/large_file   /backup_raidz_test/test_fs_copy_A/large_file 

md5sum /nas1FS/test_fs_A/large_file   /nas1FS/test_fs_A/.zfs/snapshot/$date_today"_1"/large_file /nas1FS/test_fs_A/.zfs/snapshot/$date_today"_2"/large_file /backup_raidz_test/test_fs_copy_A/large_file /backup_raidz_test/test_fs_copy_A/.zfs/snapshot/$date_today"_1"/large_file /backup_raidz_test/test_fs_copy_A/.zfs/snapshot/$date_today"_2"/large_file 

# bash zfs_hole_transmit_test.sh 
20160701
1 -rw-r--r-- 1 root root 1073741824 Jul  1 16:34 /nas1FS/test_fs_A/large_file
384+0 records in
384+0 records out
1572864 bytes (1.6 MB) copied, 0.589256 s, 2.7 MB/s
128+0 records in
128+0 records out
524288 bytes (524 kB) copied, 0.206688 s, 2.5 MB/s
10+0 records in
10+0 records out
40960 bytes (41 kB) copied, 0.0151903 s, 2.7 MB/s
1113 -rw-r--r-- 1 root root 2097152 Jul  1 16:34 /backup_raidz_test/test_fs_copy_A/large_file
2223 -rw-r--r-- 1 root root 2097152 Jul  1 16:34 /nas1FS/test_fs_A/large_file
046b704054d6e84353ec61b8665dfb9a  /nas1FS/test_fs_A/large_file
046b704054d6e84353ec61b8665dfb9a  /backup_raidz_test/test_fs_copy_A/large_file
046b704054d6e84353ec61b8665dfb9a  /nas1FS/test_fs_A/large_file
c45ee26328f1b78079a155d4b04d76d3  /nas1FS/test_fs_A/.zfs/snapshot/20160701_1/large_file
046b704054d6e84353ec61b8665dfb9a  /nas1FS/test_fs_A/.zfs/snapshot/20160701_2/large_file
046b704054d6e84353ec61b8665dfb9a  /backup_raidz_test/test_fs_copy_A/large_file
c45ee26328f1b78079a155d4b04d76d3  /backup_raidz_test/test_fs_copy_A/.zfs/snapshot/20160701_1/large_file
046b704054d6e84353ec61b8665dfb9a  /backup_raidz_test/test_fs_copy_A/.zfs/snapshot/20160701_2/large_file

# for i in $(zfs list -o mountpoint  |grep test_fs); do echo $i; for j in $(ls $i/.zfs/snapshot/ -1 );do md5s/.zfs/snapshot/$j/large_file" ; done; done;

/backup_raidz_test/test_fs_copy_A
c45ee26328f1b78079a155d4b04d76d3  /backup_raidz_test/test_fs_copy_A/.zfs/snapshot/20160701_1/large_file
046b704054d6e84353ec61b8665dfb9a  /backup_raidz_test/test_fs_copy_A/.zfs/snapshot/20160701_2/large_file
/nas1FS/test_fs
0f41e9d5956532d434572b6f06d7b082  /nas1FS/test_fs/.zfs/snapshot/20160628_1/large_file
2b1b5792f6a45d45a5399ff977ca6fda  /nas1FS/test_fs/.zfs/snapshot/20160628_2/large_file
2b1b5792f6a45d45a5399ff977ca6fda  /nas1FS/test_fs/.zfs/snapshot/20160629/large_file
2b1b5792f6a45d45a5399ff977ca6fda  /nas1FS/test_fs/.zfs/snapshot/20160629_1/large_file
2b1b5792f6a45d45a5399ff977ca6fda  /nas1FS/test_fs/.zfs/snapshot/20160629_2/large_file
2b1b5792f6a45d45a5399ff977ca6fda  /nas1FS/test_fs/.zfs/snapshot/20160629_3/large_file
/nas1FS/test_fs_A
c45ee26328f1b78079a155d4b04d76d3  /nas1FS/test_fs_A/.zfs/snapshot/20160701_1/large_file
046b704054d6e84353ec61b8665dfb9a  /nas1FS/test_fs_A/.zfs/snapshot/20160701_2/large_file

Als ich versucht habe, (auf v0.6.5.7) einen Test fs ("nas1FS/test_fs") zu übertragen, der mit den gleichen Befehlen auf v0.6.5.3 erstellt wurde, habe ich eine Prüfsummen-Nichtübereinstimmung erhalten:

# zfs send -R "nas1FS/test_fs@20160629_3" |zfs receive -F "backup_raidz_test/test_fs"
# for i in $(zfs list -o mountpoint  |grep test_fs); do echo $i; for j in $(ls $i/.zfs/snapshot/ -1 );do md5s/.zfs/snapshot/$j/large_file" ; done; done;

/backup_raidz_test/test_fs
0f41e9d5956532d434572b6f06d7b082  /backup_raidz_test/test_fs/.zfs/snapshot/20160628_1/large_file
7a8008b4cc398a0a4ad8a6c686aa0f6f  /backup_raidz_test/test_fs/.zfs/snapshot/20160628_2/large_file
7a8008b4cc398a0a4ad8a6c686aa0f6f  /backup_raidz_test/test_fs/.zfs/snapshot/20160629/large_file
7a8008b4cc398a0a4ad8a6c686aa0f6f  /backup_raidz_test/test_fs/.zfs/snapshot/20160629_1/large_file
7a8008b4cc398a0a4ad8a6c686aa0f6f  /backup_raidz_test/test_fs/.zfs/snapshot/20160629_2/large_file
7a8008b4cc398a0a4ad8a6c686aa0f6f  /backup_raidz_test/test_fs/.zfs/snapshot/20160629_3/large_file
/backup_raidz_test/test_fs_copy_A
c45ee26328f1b78079a155d4b04d76d3  /backup_raidz_test/test_fs_copy_A/.zfs/snapshot/20160701_1/large_file
046b704054d6e84353ec61b8665dfb9a  /backup_raidz_test/test_fs_copy_A/.zfs/snapshot/20160701_2/large_file
/nas1FS/test_fs
0f41e9d5956532d434572b6f06d7b082  /nas1FS/test_fs/.zfs/snapshot/20160628_1/large_file
2b1b5792f6a45d45a5399ff977ca6fda  /nas1FS/test_fs/.zfs/snapshot/20160628_2/large_file
2b1b5792f6a45d45a5399ff977ca6fda  /nas1FS/test_fs/.zfs/snapshot/20160629/large_file
2b1b5792f6a45d45a5399ff977ca6fda  /nas1FS/test_fs/.zfs/snapshot/20160629_1/large_file
2b1b5792f6a45d45a5399ff977ca6fda  /nas1FS/test_fs/.zfs/snapshot/20160629_2/large_file
2b1b5792f6a45d45a5399ff977ca6fda  /nas1FS/test_fs/.zfs/snapshot/20160629_3/large_file
/nas1FS/test_fs_A
c45ee26328f1b78079a155d4b04d76d3  /nas1FS/test_fs_A/.zfs/snapshot/20160701_1/large_file
046b704054d6e84353ec61b8665dfb9a  /nas1FS/test_fs_A/.zfs/snapshot/20160701_2/large_file

Wie soll ich vorgehen?
Wird es hilfreich sein, Images eines Pools bereitzustellen, der in v0.6.5.3 erstellt wurde und dieses Verhalten zeigt, oder andere Tests?

Anscheinend habe ich nicht genug getestet.
Das Problem besteht auch nach dem Upgrade auf v0.6.5.7.
Der Absturz beim Zugriff auf eine nicht vorhandene Datei im Snapshot tritt nicht mehr auf, aber ich kann immer noch die Sende-/Empfangs-Snapshot-Beschädigung auslösen.
Zuvor habe ich Befehle von Hand eingegeben oder aus dem Konsolenverlauf wiederholt, sodass ich einige erhebliche Verzögerungen zwischen den Befehlen eingeführt habe.
Später habe ich das Testen zu stark automatisiert und dadurch wurde der Fehler nicht ausgelöst (auch wenn ich versucht habe ihn auf v0.6.5.3 auszulösen).

Ich habe nochmal mit folgendem Skript getestet:

#!/bin/bash
for i in $(seq 0 1 10); # sleep time loop
do 
for j in $(seq 1 1 10); #pool size loop
do 

pool_name="zfs_pool_v0.6.5.7_A_"$i"s_$j"
src_fs="$pool_name/test_fs_A"
target_fs="$pool_name/test_fs_B"
date_today="20160702"
echo $pool_name ; echo $src_fs ; echo $target_fs; echo $date_today

dd if=/dev/zero of=/nas1FS/tmp/$pool_name bs=4k count=$(($j*128*128)) # pool size has an impact on bug triggeringl 
zpool create -o ashift=12 $pool_name /nas1FS/tmp/$pool_name
zfs create -o recordsize=4k $src_fs
zfs set compression=on $src_fs

truncate -s 1G /$src_fs/large_file
ls  -als /$src_fs/large_file
dd if=/dev/urandom of=/$src_fs/large_file bs=4k count=$((3*128)) seek=$((1*128))
zfs snapshot $src_fs@$date_today"_1"
truncate -s $((2*128*4*1024)) /$src_fs/large_file
dd if=/dev/urandom of=/$src_fs/large_file bs=4k count=128 seek=$((3*128)) conv=notrunc
sleep $i; #10; # <=this sleep is critical for triggering the bug when pool is large enough
dd if=/dev/urandom of=/$src_fs/large_file bs=4k count=10 seek=$((2*128)) conv=notrunc
zfs snapshot $src_fs@$date_today"_2"
zfs send -R $src_fs@$date_today"_2" |zfs recv $target_fs

ls -als /$src_fs/large_file /$target_fs/large_file

md5sum /$src_fs/.zfs/snapshot/$date_today"_1"/large_file /$target_fs/.zfs/snapshot/$date_today"_1"/large_file
md5sum /$src_fs/.zfs/snapshot/$date_today"_2"/large_file /$target_fs/.zfs/snapshot/$date_today"_2"/large_file
md5sum /$src_fs/large_file /$target_fs/large_file

md5sum /$src_fs/.zfs/snapshot/$date_today"_1"/large_file /$target_fs/.zfs/snapshot/$date_today"_1"/large_file >> /nas1FS/tmp/final_test_md5sums.txt>> /nas1FS/tmp/final_test_md5sums.txt
md5sum /$src_fs/.zfs/snapshot/$date_today"_2"/large_file /$target_fs/.zfs/snapshot/$date_today"_2"/large_file >> /nas1FS/tmp/final_test_md5sums.txt>> /nas1FS/tmp/final_test_md5sums.txt
md5sum /$src_fs/large_file /$target_fs/large_file >> /nas1FS/tmp/final_test_md5sums.txt>> /nas1FS/tmp/final_test_md5sums.txt
zpool export $pool_name
done; 
done;

Dieses Skript wiederholte den gleichen Poolerstellungs-/Dateierstellungs-/Snapshot-/Übertragungszyklus für verschiedene Poolgrößen und mit unterschiedlichen Verzögerungen zwischen den Dateiänderungen.
Es scheint, dass das Sende-/Empfangsproblem nur ausgelöst wurde, wenn die Verzögerung länger als 4 Sekunden war oder wenn die Größe des Bildes, das den Pool enthält, klein war (2^26 Byte).

Matrix der getesteten Werte für Verzögerungen / Pool-Image-Größe (beschädigter Snapshot-Übertragungsfehler wurde bei Werten ausgelöst, die sich in rot markierten Bereichen überschneiden):

Ich spekuliere nur, aber ist es möglich, dass das Problem irgendwie mit der Synchronisierung von Daten mit der Festplatte zusammenhängt (die Synchronisierung von Daten vom Speicher auf die Festplatte ist nicht konsistent)?

@pwolny

Was sind die SMART-Statistiken für diese Laufwerke? irgendwas ungewöhnliches?

kannst du die irgendwo posten?

smartctl -x /dev/foo

Gibt es eine Möglichkeit umzutauschen

“backup_raidz_test” pool: 1TB Samsung HD103UJ (pool with no parity, for additional tests)

und/oder Kabel

für ein anderes Laufwerk?

Alle Laufwerke sind mit demselben Festplattencontroller verbunden?
http://www.supermicro.com/products/motherboard/Atom/X10/A1SA7-2750F.cfm

LSI 2116-Controller für 16x SATA3 /
SAS2-Ports plus 1x SATA3-SMCI
SATA-DOM

sind irgendwelche Probleme mit diesen und ZFS bekannt?

Firmware- oder Treiberupdates?

das fällt mir jetzt zumindest ein...

@kernelOfTruth

alle Festplatten scheinen in Ordnung zu sein. nichts ungewöhnliches an ihnen von smartctl.

nas1FS-Laufwerke sind in smartctl sehr ähnlich:

smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.16.0-4-amd64] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     HGST Travelstar 7K1000
Device Model:     HGST HTS721010A9E630
Firmware Version: JB0OA3J0
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      2.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 6
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sun Jul  3 08:41:18 2016 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM level is:     254 (maximum performance)
Rd look-ahead is: Enabled
Write cache is:   Enabled
ATA Security is:  Disabled, NOT FROZEN [SEC1]
Wt Cache Reorder: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                    was never started.
                    Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                    without error or no self-test has ever 
                    been run.
Total time to complete Offline 
data collection:        (   45) seconds.
Offline data collection
capabilities:            (0x5b) SMART execute Offline immediate.
                    Auto Offline data collection on/off support.
                    Suspend Offline collection upon new
                    command.
                    Offline surface scan supported.
                    Self-test supported.
                    No Conveyance Self-test supported.
                    Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                    power-saving mode.
                    Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                    General Purpose Logging supported.
Short self-test routine 
recommended polling time:    (   2) minutes.
Extended self-test routine
recommended polling time:    ( 171) minutes.
SCT capabilities:          (0x003d) SCT Status supported.
                    SCT Error Recovery Control supported.
                    SCT Feature Control supported.
                    SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
  1 Raw_Read_Error_Rate     PO-R--   100   100   062    -    0
  2 Throughput_Performance  P-S---   100   100   040    -    0
  3 Spin_Up_Time            POS---   114   114   033    -    2
  4 Start_Stop_Count        -O--C-   100   100   000    -    16
  5 Reallocated_Sector_Ct   PO--CK   100   100   005    -    0
  7 Seek_Error_Rate         PO-R--   100   100   067    -    0
  8 Seek_Time_Performance   P-S---   100   100   040    -    0
  9 Power_On_Hours          -O--C-   100   100   000    -    208
 10 Spin_Retry_Count        PO--C-   100   100   060    -    0
 12 Power_Cycle_Count       -O--CK   100   100   000    -    16
191 G-Sense_Error_Rate      -O-R--   100   100   000    -    0
192 Power-Off_Retract_Count -O--CK   100   100   000    -    13
193 Load_Cycle_Count        -O--C-   100   100   000    -    57
194 Temperature_Celsius     -O----   222   222   000    -    27 (Min/Max 20/35)
196 Reallocated_Event_Count -O--CK   100   100   000    -    0
197 Current_Pending_Sector  -O---K   100   100   000    -    0
198 Offline_Uncorrectable   ---R--   100   100   000    -    0
199 UDMA_CRC_Error_Count    -O-R--   200   200   000    -    0
223 Load_Retry_Count        -O-R--   100   100   000    -    0
                            ||||||_ K auto-keep
                            |||||__ C event count
                            ||||___ R error rate
                            |||____ S speed/performance
                            ||_____ O updated online
                            |______ P prefailure warning

General Purpose Log Directory Version 1
SMART           Log Directory Version 1 [multi-sector log support]
Address    Access  R/W   Size  Description
0x00       GPL,SL  R/O      1  Log Directory
0x01           SL  R/O      1  Summary SMART error log
0x02           SL  R/O      1  Comprehensive SMART error log
0x03       GPL     R/O      1  Ext. Comprehensive SMART error log
0x06           SL  R/O      1  SMART self-test log
0x07       GPL     R/O      1  Extended self-test log
0x09           SL  R/W      1  Selective self-test log
0x10       GPL     R/O      1  SATA NCQ Queued Error log
0x11       GPL     R/O      1  SATA Phy Event Counters log
0x80-0x9f  GPL,SL  R/W     16  Host vendor specific log
0xe0       GPL,SL  R/W      1  SCT Command/Status
0xe1       GPL,SL  R/W      1  SCT Data Transfer

SMART Extended Comprehensive Error Log Version: 1 (1 sectors)
No Errors Logged

SMART Extended Self-test Log Version: 1 (1 sectors)
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

SCT Status Version:                  3
SCT Version (vendor specific):       256 (0x0100)
SCT Support Level:                   1
Device State:                        Active (0)
Current Temperature:                    27 Celsius
Power Cycle Min/Max Temperature:     26/27 Celsius
Lifetime    Min/Max Temperature:     20/35 Celsius
Lifetime    Average Temperature:        28 Celsius
Under/Over Temperature Limit Count:   0/0

SCT Temperature History Version:     2
Temperature Sampling Period:         1 minute
Temperature Logging Interval:        1 minute
Min/Max recommended Temperature:      0/60 Celsius
Min/Max Temperature Limit:           -40/65 Celsius
Temperature History Size (Index):    128 (106)

Index    Estimated Time   Temperature Celsius
 107    2016-07-03 06:34    28  *********
 ...    ..(114 skipped).    ..  *********
  94    2016-07-03 08:29    28  *********
  95    2016-07-03 08:30     ?  -
  96    2016-07-03 08:31    26  *******
  97    2016-07-03 08:32    26  *******
  98    2016-07-03 08:33    27  ********
 ...    ..(  7 skipped).    ..  ********
 106    2016-07-03 08:41    27  ********

SCT Error Recovery Control:
           Read: Disabled
          Write: Disabled

Device Statistics (GP/SMART Log 0x04) not supported

SATA Phy Event Counters (GP Log 0x11)
ID      Size     Value  Description
0x0001  2            0  Command failed due to ICRC error
0x0002  2            0  R_ERR response for data FIS
0x0003  2            0  R_ERR response for device-to-host data FIS
0x0004  2            0  R_ERR response for host-to-device data FIS
0x0005  2            0  R_ERR response for non-data FIS
0x0006  2            0  R_ERR response for device-to-host non-data FIS
0x0007  2            0  R_ERR response for host-to-device non-data FIS
0x0009  2            3  Transition from drive PhyRdy to drive PhyNRdy
0x000a  2            3  Device-to-host register FISes sent due to a COMRESET
0x000b  2            0  CRC errors within host-to-device FIS
0x000d  2            0  Non-CRC errors within host-to-device FIS

Alle Festplatten sind mit dem gleichen Controller (LSI) auf A1SA7-2750F verbunden, das Motherboard ist wie empfangen (keine FW-Updates).

Ich habe die Tests mit dem Pool wiederholt, der von einer Ramdisk-Datei unterstützt wird, also keine fehlerhaften Kabel oder Controller und ich kann den Fehler immer noch mit einem Skript von https://github.com/zfsonlinux/zfs/issues/4809#issuecomment -230123528 auslösen

Ich habe auch auf einem Laptop erneut getestet:
Linux 4.5.0-1-amd64 #1 SMP Debian 4.5.1-1 (2016-04-14) x86_64 GNU/Linux
mit spl/zfs v0.6.5.7 mit dem Pool, der von einer Ramdisk-Datei mit dem oben genannten Skript unterstützt wird, und ich kann es auch auslösen.

Ich habe auf einem anderen (viel älteren) Computer erneut getestet:
Linux 2.6.38-2-amd64 #1 SMP Sun May 8 13:51:57 UTC 2011 x86_64 GNU/Linux
mit spl/zfs v0.6.0 mit dem Pool gesichert durch eine Ramdisk-Datei mit oben genanntem Skript und ich kann es nicht auslösen.

@pwolny Ich https://gist.github.com/lnicola/1e069f2abaee1dbaaeafc05437b0777a

@lnicola Es scheint, dass Ihre Skriptausgabe den gleichen Fußabdruck von Prüfsummenfehlanpassungen aufweist wie meine. Welche Kernel-/ZFS-Version hast du verwendet?

Sorry, dass ich die nicht erwähnt habe. Ich bin auf 4.6.3-1-ARCH mit 0.6.5.7_4.6.3_1-1, also den neusten Versionen.

Das ist ziemlich besorgniserregend, ich sichere meine Dateien heutzutage auch meistens nur mit zfs send & laufe auch 4.6.3 - ZFS ist für mich oben auf cryptsetup,

@pwolny verwenden Sie einen Verschlüsselungs- oder Partitionsänderungsmechanismus (cryptsetup, lvm usw.)?

@pwolny @lnicola laufen Ihre Pools mit den neuesten ZFS-Features?

Was sagt der Befehl zpool upgrade?

(Ich kann derzeit keine Beispielausgabe meines Pools bereitstellen, da ich in Windows bin, habe es seit einiger Zeit nicht mehr aktualisiert, soweit ich weiß, fehlen noch 2 in meinem /home-Pool)

_bearbeiten:_

Bin momentan anderweitig beschäftigt, werde aber später am Tag mal sehen, ob ich es auch hier reproduzieren kann

Verweis auf https://github.com/zfsonlinux/zfs/pull/4754 (6513 teilweise gefüllte Löcher verlieren Geburtszeit), der im Master ist: https://github.com/zfsonlinux/zfs/commit/bc77ba73fec82d37c0b57949ec29edd9aa207677

@kernelOfTruth ja, ich habe hole_birth aktiv.

@pwolny Sie verlassen sich darauf, dieses Problem mit dem Samsung-Laufwerk und der gzip-9-Komprimierung zu zeigen.

I have created a “backup_raidz” pool for backup (with compression turned on): 
# zpool create -o ashift=12 -O compression=gzip-9 backup_raidz raidz1 /dev/disk/by-id/ata-SAMSUNG_HD103UJ_SerialNo1 /dev/disk/by-id/ata-SAMSUNG_HD103UJ_SerialNo2 /dev/disk/by-id/ata-HGST_HTS721010A9E630_SerialNo3 -f

passiert dies auch, wenn Sie die lz4-Komprimierung explizit einstellen?

oder eine der anderen Arten?

Referenzierung: https://github.com/zfsonlinux/zfs/issues/4530 Datenbeschädigung beim Senden/Empfangen von ZFS

@pwolny bitte https://github.com/zfsonlinux/zfs/issues/4530#issuecomment -211996617 insbesondere den Teil im Zusammenhang mit der Zerstörung des Snapshots

@kernelOfTruth

• Ich habe Geräte direkt an zpool übergeben, kein cryptsetup oder ähnliches.
• Ich denke, dass ich absichtlich nur die Komprimierungseinstellung auf einen anderen Wert als den Standardwert geändert habe.
• Als ich dieses Problem (auf mehreren Versionen von spl/zfs) mit einem Skript getestet habe, hatten alle Funktionseinstellungen Standardwerte aus der getesteten zfs-Version.
• Ich habe auf meinem Laptop erneut ohne Komprimierung getestet (Pool, der durch eine Datei auf der Ramdisk gesichert ist) und das Problem ist vorhanden (sowohl für eine Verzögerung von 5 Sekunden oder länger als auch bei einer Pool-Image-Größe von 64 MiB), also hängt es wahrscheinlich nicht mit der Komprimierung zusammen.

Über die #4530 (Kommentar):

• Ich habe mit dem Zerstören und erneuten Senden der Snapshots (teilweise und vollständiger Datensatz) herumgespielt und konnte dieses Problem auf diese Weise nicht beseitigen.
• Ich hatte auch neue Snapshots erstellt, aber ohne Änderung des Sende-/Empfangsproblems begann das Problem in meinem Pool beim frühesten Snapshot, also hatte ich wahrscheinlich ganz andere Bedingungen.
• Vielleicht ist die erwähnte neue Maschine schneller und kann den Fehler deswegen nicht auslösen?
• Ich kann den Fehler sehr zuverlässig mit frischen Pools (auf null abgelegten Dateien) auslösen. Selbst wenn er später maskiert werden kann, wollen wir ihn einfach maskieren und dort belassen?

@pwolny Was ist, wenn Sie die Verwendung von truncate durch dd ersetzen?

Ich habe mehrere Versionen von spl/zfs (aus dem Quellcode erstellt) auf einer virtuellen Maschine mit Knoppix 7.4.2 mit Kernel erneut getestet
Linux Microknoppix 3.16.3-64 #10 SMP PREEMPT Fri Sep 26 02:00:22 CEST 2014 x86_64 GNU/Linux
und ich kann dieses Problem sehr zuverlässig reproduzieren (mit dem in https://github.com/zfsonlinux/zfs/issues/4809#issuecomment-230123528 erwähnten Skript).

Beim Testen habe ich drei mögliche Fußabdrücke gesehen:

• alle Snapshots übertragen ok für zfs v0.6.3.1-1.3
  
• übertragene Snapshots hatten Fehler, wenn eine Verzögerung von 5s oder länger für zfs v0.6.4 eingeführt wurde; v0.6.4.1; v0.6.4.2
  
• übertragene Snapshots hatten Fehler wegen eingeführter Verzögerung von 5s oder länger oder wenn die Pool-Image-Größe 64MiB für zfs v0.6.5 betrug; v0.6.5.2; v0.6.5.7;
  

Um die getesteten Versionen (unterschiedliche Soft- und Hardware) zusammenzufassen:
v0.6.0-rc8 - ist in Ordnung
v0.6.3.1-1.3 - ist in Ordnung
v0.6.4 - weist den Fehler teilweise auf
v0.6.4.1 - weist den Fehler teilweise auf
v0.6.4.2 - weist den Fehler teilweise auf
v0.6.5 - zeigt den Fehler vollständig an
v0.6.5.2 - zeigt den Fehler vollständig an
v0.6.5.3 - zeigt den Fehler vollständig an
v0.6.5.7 - zeigt den Fehler vollständig an

Es scheint also, dass das Problem (oder möglicherweise zwei) kurz vor v0.6.4 eingeführt und möglicherweise in v0.6.5 verschärft wurde.

@lnicola Wenn ich ersetze:
truncate -s 1G /$src_fs/large_file
mit
dd if=/dev/zero of=/$src_fs/large_file bs=1 count=1 seek=1G
Ich kann den Fehler immer noch vollständig auslösen.

Was ist mit der anderen truncate Nutzung? Ich denke, es könnte beweisen, dass dies nicht mit der Funktion hole_birth .

Ich habe einige Modifikationen des Testskripts getestet.
Dies ist der relevante Teil dieses Tests:

dd if=/dev/zero of="$pool_file_path/$pool_name" bs=4k count=$(($j*128*128)) # pool size has an impact on bug triggeringl 
zpool create -o ashift=12 $pool_name "$pool_file_path/$pool_name"
zfs create -o recordsize=4k $src_fs
zfs set compression=on $src_fs

#========================1st truncate/dd=====================================#
truncate -s 1G /$src_fs/large_file #possible to trigger the bug
#dd if=/dev/zero of=/$src_fs/large_file bs=1G count=1 #possible to trigger the bug
#dd if=/dev/zero of=/$src_fs/large_file bs=1G count=1 conv=notrunc #possible to trigger the bug
#========================1st truncate/dd=====================================#

ls  -als /$src_fs/large_file

dd if=/dev/urandom of=/$src_fs/large_file bs=4k count=$((3*128)) seek=$((1*128))
zfs snapshot $src_fs@$date_today"_1"

#========================2nd truncate/dd=====================================#
truncate -s $((2*128*4*1024)) /$src_fs/large_file #possible to trigger bug
#truncate -s $((2*128*4*1024+1)) /$src_fs/large_file #not triggerring the bug
#dd if=/dev/zero of=/$src_fs/large_file bs=1 count=1 seek=$((2*128*4*1024)) #not triggering the bug
#dd if=/dev/zero of=/$src_fs/large_file bs=1 count=1 seek=$((2*128*4*1024-1)) #possible to trigger bug
#dd if=/dev/zero of=/$src_fs/large_file bs=1 count=1 seek=$((2*128*4*1024-1)) conv=notrunc #with this the bug never triggers
#========================2nd truncate/dd=====================================#

ls  -als /$src_fs/large_file

dd if=/dev/urandom of=/$src_fs/large_file bs=4k count=128 seek=$((3*128)) conv=notrunc
sleep $i; #10; # <=this sleep is critical for triggering the bug when pool is large enough
dd if=/dev/urandom of=/$src_fs/large_file bs=4k count=10 seek=$((2*128)) conv=notrunc
zfs snapshot $src_fs@$date_today"_2"

Es scheint, dass nur der zweite Befehl truncate/dd einen Einfluss auf das Auslösen des Problems hat.

Vielleicht findet jemand diese Version des Skripts nützlich:
zfs_test3.sh.txt

Es wird versuchen, eine Datei "test_matrix_output.txt" im Verzeichnis "/tmp/zfs" zu erstellen (das Skript erstellt dieses Verzeichnis nicht).
Wenn in dieser Datei ein "E" vorhanden ist, bedeutet dies, dass eine Prüfsummenabweichung zwischen dem übertragenen Quell- und Ziel-Snapshot aufgetreten ist.
Wenn die Matrix nur mit "o" gefüllt ist, ist alles ok.

Beispiel "test_matrix_output.txt" mit Fehlern sieht so aus (Ausgabe mit spl/zfs v0.6.5.7)

oooooEEEEEE
oooooEEEEEE
oooooEEEEEE
oooooEEEEEE

Hallo, pwolny,

Kann der Fehler im Interesse der Klarheit reproduziert werden, indem eine Version eines Skripts mit angemessener Häufigkeit ausgeführt wird, und wenn ja, könnten Sie bitte die kürzeste Version eines solchen Skripts veröffentlichen?

Idealerweise umfasst das Skript die Erstellung und Bereinigung eines Pools basierend auf Datei-vdevs. Ich versuche, die Site-Besonderheiten abzustrahieren. Die Originalausgaben mit teilweise gefüllten Löchern und wiederverwendeten Dnoden (Illumos 6370, Illumos 6513) lassen sich meines Wissens auf solchen Becken reproduzieren.

Viele Grüße, Boris.

Von: pwolny [email protected]
Gesendet: Dienstag, 5. Juli 2016 19:35:00
An: zfsonlinux/zfs
Cc: Boris Protopopov; Erwähnen
Betreff: Re: [zfsonlinux/zfs] Unbemerkt beschädigte Datei in Snapshots nach dem Senden/Empfangen (#4809)

Vielleicht findet jemand diese Version des Skripts nützlich:
zfs_test3.sh. txthttps://github.com/zfsonlinux/zfs/files/348819/zfs_test3.sh.txt

Es wird versuchen, eine Datei "test_matrix_output.txt" im Verzeichnis "/tmp/zfs" zu erstellen (das Skript erstellt dieses Verzeichnis nicht).
Wenn in dieser Datei ein "E" vorhanden ist, bedeutet dies, dass eine Prüfsummenabweichung zwischen dem übertragenen Quell- und Ziel-Snapshot aufgetreten ist.
Wenn die Matrix nur mit "o" gefüllt ist, ist alles ok.

Beispiel "test_matrix_output.txt" mit Fehlern sieht so aus (Ausgabe mit spl/zfs v0.6.5.7)

EEEEEEEEEEE
oooooEEEEEE
oooooEEEEEE
oooooEEEEEE
oooooEEEEEE

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie auf diese E - Mail direkt, sehen sie auf Gi tHubhttps: //github.com/zfsonlinux/zfs/issues/4809#issuecomment -230.633.478 oder stumm schalten die th readhttps: //github.com/notifications/unsubscribe/ACX4uUHtdxskZcz_gzXobTL9IrTNjSpWks5qSuokgaJpZM4I-nnL.

Hallo @bprotopopov ,
Grundsätzlich enthält dieses Skript Befehle, die Sie am 3. Dezember 2015 im Fehlerbericht #4050 vorgeschlagen haben. Lediglich eine variable Zeitverzögerung und die Größe der Pool-Backing-Datei sind für das Triggern kritische Ergänzungen, der Rest wurde nur für die Testautomatisierung benötigt.

Löst es nicht auf Ihrem System aus? Gibt es "E"-Buchstaben in der Datei "test_matrix_output.txt" im Verzeichnis "/tmp/zfs"?
Bei mir löst das Skript in "zfs_test3.sh.txt" immer auf betroffenen Systemen aus. Es kann auch helfen, zwischen 2 Arten von ausgelöstem Verhalten zu unterscheiden (bitte werfen Sie einen Blick auf frühere Beiträge mit Bildern, die verschiedene Fußabdrücke zeigen, die von diesem Skript für verschiedene zfs / spl-Versionen generiert werden).

Wenn Sie die Testzeit minimieren müssen, stellen Sie einfach Folgendes ein:
Einschlafzeit in Schleife bis 6 Sekunden Verzögerung " $(seq 6 1 6)"
und Poolgrößenschleife zum 1. Größenmultiplikator "$(seq 1 1 1)"
es sollte immer auf einem betroffenen System auslösen, aber auf diese Weise verlieren Sie die Möglichkeit, zwischen den ausgelösten Effekten zu unterscheiden.

Jedenfalls erstellt die neueste Skriptversion einen Pool, der von einer Datei unterstützt wird, und entfernt ihn anschließend, tatsächlich macht sie das insgesamt etwa 55 Mal in der Testschleife.
Es gibt sogar einen Exit-Status ungleich Null im Fehlerfall zurück.
Wenn Sie es in einer automatischen und Headless-Testumgebung verwenden möchten, müssen Sie die 3 Zeilen wahrscheinlich mit "weniger" am Ende auskommentieren.
Vielleicht bleiben einige Textdateien im Ordner "/tmp/zfs/", aber ich wollte sie zur Überprüfung haben.

Mit freundlichen Grüßen

Ich habe einige Regressionstests durchgeführt und es scheint, dass der Fehler in diesem Commit eingeführt wurde (zfs-0.6.3-27):

b0bc7a84d90dcbf5321d48c5b24ed771c5a128b0 Illumos 4370, 4371 (4370 avoid transmitting holes during zfs send ;4371 DMU code clean up)

Es erzeugt folgenden Fußabdruck:

oooooEEEEEE
oooooEEEEEE
oooooEEEEEE
oooooEEEEEE 

Während ein vorheriger Commit (zfs-0.6.3-26)

fa86b5dbb6d33371df344efb2adb0aba026d097c Illumos 4171, 4172
erzeugt keine Fehler

ooooooooooo
ooooooooooo
ooooooooooo
ooooooooooo

Beide wurden mit spl-0.6.3-10 getestet, commit :

e3020723dc43af2bc22af0d68571a61daf9b44d0 Linux 3.16 compat: smp_mb__after_clear_bit()

Könnte sich jemand diese Codeänderungen ansehen? Leider ist das so weit, wie ich mit der Fehlersuche gehen kann.

Okay, großartig,

lass mich mal kurz nachsehen.

Boris.

Von: pwolny [email protected]
Gesendet: Donnerstag, 7. Juli 2016 00:09:41
An: zfsonlinux/zfs
Cc: Boris Protopopov; Erwähnen
Betreff: Re: [zfsonlinux/zfs] Unbemerkt beschädigte Datei in Snapshots nach dem Senden/Empfangen (#4809)

Hallo @bprotopopovhttps://github.com/bprotopopov ,
Grundsätzlich enthält dieses Skript Befehle, die Sie am 3. Dezember 2015 im Fehlerbericht #4050 https://github.com/zfsonlinux/zfs/issues/4050 vorgeschlagen haben. Lediglich eine variable Zeitverzögerung und die Größe der Pool-Backing-Datei sind für das Triggern kritische Ergänzungen, der Rest wurde nur für die Testautomatisierung benötigt.

Löst es nicht auf Ihrem System aus? Gibt es "E"-Buchstaben in der Datei "test_matrix_output.txt" im Verzeichnis "/tmp/zfs"?
Bei mir löst das Skript in "zfs_test3.sh.txt" immer auf betroffenen Systemen aus. Es kann auch helfen, zwischen 2 Arten von ausgelöstem Verhalten zu unterscheiden (bitte werfen Sie einen Blick auf frühere Beiträge mit Bildern, die verschiedene Fußabdrücke zeigen, die von diesem Skript für verschiedene zfs / spl-Versionen generiert werden).

Wenn Sie die Testzeit minimieren müssen, stellen Sie einfach Folgendes ein:
Einschlafzeit in Schleife bis 6 Sekunden Verzögerung " $(seq 6 1 6)"
und Poolgrößenschleife zum 1. Größenmultiplikator "$(seq 1 1 1)"
es sollte immer auf einem betroffenen System auslösen, aber auf diese Weise verlieren Sie die Möglichkeit, zwischen den ausgelösten Effekten zu unterscheiden.

Jedenfalls erstellt die neueste Skriptversion einen Pool, der von einer Datei unterstützt wird, und entfernt ihn anschließend, tatsächlich macht sie das insgesamt etwa 55 Mal in der Testschleife.
Es gibt sogar einen Exit-Status ungleich Null im Fehlerfall zurück.

Wenn Sie es in einer automatischen und Headless-Testumgebung verwenden möchten, müssen Sie die 3 Zeilen wahrscheinlich mit "weniger" am Ende auskommentieren.
Vielleicht bleiben einige Textdateien im Ordner "/tmp/zfs/", aber ich wollte sie zur Überprüfung haben.

Mit freundlichen Grüßen

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie auf diese E - Mail direkt, sehen sie auf Gi tHubhttps: //github.com/zfsonlinux/zfs/issues/4809#issuecomment -230.974.519 oder stumm schalten die th readhttps: //github.com/notifications/unsubscribe/ACX4uWNV7Z2Y0pLNkPsWO7i2EXiMfrJdks5qTHwFgaJpZM4I-nnL.

Nun, das scheint angemessen - der fragliche Commit scheint Unterstützung für das hole_birth-Feature einzuführen.

Von: pwolny [email protected]
Gesendet: Donnerstag, 7. Juli 2016 08:26:34
An: zfsonlinux/zfs
Cc: Boris Protopopov; Erwähnen
Betreff: Re: [zfsonlinux/zfs] Unbemerkt beschädigte Datei in Snapshots nach dem Senden/Empfangen (#4809)

Ich habe einige Regressionstests durchgeführt und es scheint, dass der Fehler in diesem Commit eingeführt wurde (zfs-0.6.3-27):

b0bc7a8 https://github.com/zfsonlinux/zfs/commit/b0bc7a84d90dcbf5321d48c5b24ed771c5a128b0 Illumos 4370, 4371 (4370 Übertragungslöcher beim ZFS-Senden vermeiden ;4371 DMU-Code-Bereinigung)
Es erzeugt folgenden Fußabdruck:

oooooEEEEEE
oooooEEEEEE
oooooEEEEEE
oooooEEEEEE
oooooEEEEEE

Während ein vorheriger Commit (zfs-0.6.3-26)

fa86b5 dhttps://github.com/zfsonlinux/zfs/commit/fa86b5dbb6d33371df344efb2adb0aba026d097c Illumos 4171, 4172
erzeugt keine Fehler

oooooooooooo
oooooooooooo
oooooooooooo
oooooooooooo
oooooooooooo

Beide wurden mit spl-0.6.3-10 getestet, commit :

e302072 https://github.com/zfsonlinux/zfs/commit/e3020723dc43af2bc22af0d68571a61daf9b44d0 Linux 3.16 Kompat: smp_mb__after_clear_bit()

Könnte sich jemand diese Codeänderungen ansehen? Leider ist das so weit, wie ich mit der Fehlersuche gehen kann.

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie auf diese E - Mail direkt, sehen sie auf Gi tHubhttps: //github.com/zfsonlinux/zfs/issues/4809#issuecomment -231.062.968 oder stumm schalten die th readhttps: //github.com/notifications/unsubscribe/ACX4uaT4Rqoxawi8RNa5Fxdtaz6slTWCks5qTPB6gaJpZM4I-nnL.

Für alle, die sich Sorgen machen, kann dieses Skript helfen, spärliche Dateien zu finden: http://unix.stackexchange.com/a/86446.

BEARBEITEN: Während das Skript funktioniert, findet es nur Dateien mit geringer Dichte, keine von diesem Problem betroffenen Dateien. Je nach Arbeitsauslastung, Daten- und Komprimierungseinstellung haben Sie möglicherweise nur sehr wenige Dateien mit geringer Dichte auf einem Laufwerk. In solchen Fällen ist es besser, sich nur um diese spezifischen Dateien zu kümmern.

Auch wenn die Komprimierung deaktiviert ist, führt das Erstellen einer Kopie einer Ersatzdatei zu einer Nicht-Sparsedatei. Dies kann verwendet werden, um die zugrunde liegende Beschädigung des Quellpools zu beheben. Sobald der Fehler/die Fehler behoben sind, funktioniert das Erstellen einer Kopie auch, wenn die Komprimierung aktiviert ist.

Hallo @pwolny ,

Ich habe Ihr Skript (für eine Weile) mit einem 0.6.3-basierten ZFS und den oben genannten Fixes ausgeführt:

Commit c183d75b2bf163fa5feef301dfc9c2db885cc652
Autor: Paul Dagnelie [email protected]
Datum: So. 15. Mai 08:02:28 2016 -0700

OpenZFS 6513 - partially filled holes lose birth time

Reviewed by: Matthew Ahrens <[email protected]>
Reviewed by: George Wilson <[email protected]>
Reviewed by: Boris Protopopov <[email protected]>
Approved by: Richard Lowe <[email protected]>a
Ported by: Boris Protopopov <[email protected]>
Signed-off-by: Boris Protopopov <[email protected]>
Signed-off-by: Brian Behlendorf <[email protected]>

OpenZFS-issue: https://www.illumos.org/issues/6513
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/8df0bcf0

If a ZFS object contains a hole at level one, and then a data block is
created at level 0 underneath that l1 block, l0 holes will be created.
However, these l0 holes do not have the birth time property set; as a
result, incremental sends will not send those holes.

Fix is to modify the dbuf_read code to fill in birth time data.

begehen a29427227090abdaa2d63bfdb95746362a0504c1
Autor: Alex Reece [email protected]
Datum: Do 21. Apr 11:23:37 2016 -0700

Illumos 6844 - dnode_next_offset can detect fictional holes

6844 dnode_next_offset can detect fictional holes
Reviewed by: Matthew Ahrens <[email protected]>
Reviewed by: George Wilson <[email protected]>
Reviewed by: Brian Behlendorf <[email protected]>

dnode_next_offset is used in a variety of places to iterate over the
holes or allocated blocks in a dnode. It operates under the premise that
it can iterate over the blockpointers of a dnode in open context while
holding only the dn_struct_rwlock as reader. Unfortunately, this premise
does not hold.

When we create the zio for a dbuf, we pass in the actual block pointer
in the indirect block above that dbuf. When we later zero the bp in
zio_write_compress, we are directly modifying the bp. The state of the
bp is now inconsistent from the perspective of dnode_next_offset: the bp
will appear to be a hole until zio_dva_allocate finally finishes filling
it in. In the meantime, dnode_next_offset can detect a hole in the dnode
when none exists.

I was able to experimentally demonstrate this behavior with the
following setup:
1. Create a file with 1 million dbufs.
2. Create a thread that randomly dirties L2 blocks by writing to the
first L0 block under them.
3. Observe dnode_next_offset, waiting for it to skip over a hole in the
middle of a file.
4. Do dnode_next_offset in a loop until we skip over such a non-existent
hole.

The fix is to ensure that it is valid to iterate over the indirect
blocks in a dnode while holding the dn_struct_rwlock by passing the zio
a copy of the BP and updating the actual BP in dbuf_write_ready while
holding the lock.

References:
  https://www.illumos.org/issues/6844
  https://github.com/openzfs/openzfs/pull/82
  DLPX-35372

Ported-by: Brian Behlendorf <[email protected]>
Closes #4548

begehen f506a3da14d7ef75752df9311354e4ea4dc3354d
Autor: Paul Dagnelie [email protected]
Datum: Do 25. Feb 20:45:19 2016 -0500

Illumos 6370 - ZFS send fails to transmit some holes

6370 ZFS send fails to transmit some holes
Reviewed by: Matthew Ahrens <[email protected]>
Reviewed by: Chris Williamson <[email protected]>
Reviewed by: Stefan Ring <[email protected]>
Reviewed by: Steven Burgess <[email protected]>
Reviewed by: Arne Jansen <[email protected]>
Approved by: Robert Mustacchi <[email protected]>

References:
  https://www.illumos.org/issues/6370
  https://github.com/illumos/illumos-gate/commit/286ef71

In certain circumstances, "zfs send -i" (incremental send) can produce
a stream which will result in incorrect sparse file contents on the
target.

The problem manifests as regions of the received file that should be
sparse (and read a zero-filled) actually contain data from a file that
was deleted (and which happened to share this file's object ID).

Note: this can happen only with filesystems (not zvols, because they do
not free (and thus can not reuse) object IDs).

Note: This can happen only if, since the incremental source (FromSnap),
a file was deleted and then another file was created, and the new file
is sparse (i.e. has areas that were never written to and should be
implicitly zero-filled).

We suspect that this was introduced by 4370 (applies only if hole_birth
feature is enabled), and made worse by 5243 (applies if hole_birth
feature is disabled, and we never send any holes).

The bug is caused by the hole birth feature. When an object is deleted
and replaced, all the holes in the object have birth time zero. However,
zfs send cannot tell that the holes are new since the file was replaced,
so it doesn't send them in an incremental. As a result, you can end up
with invalid data when you receive incremental send streams. As a
short-term fix, we can always send holes with birth time 0 (unless it's
a zvol or a dataset where we can guarantee that no objects have been
reused).

Ported-by: Steven Burgess <[email protected]>
Signed-off-by: Brian Behlendorf <[email protected]>
Closes #4369
Closes #4050

Ich konnte keine Probleme reproduzieren. Alle Tests bestanden.

Ich arbeite auf einem Centos-6.7-Rechner.

Ich werde jetzt den Tipp des zfsonlinux-Masters ausprobieren.

Alles OK für ZFS 0.6.5-329_g5c27b29 und die passende SPL 0.6.5-63_g5ad98ad getestet.

@bprotopopov ist es möglich, dass dies ein Problem mit Code ist, der auf bestimmten Plattformen falsch kompiliert wird? Ich kann niemanden im Thread sehen, der auf CentOS läuft.

e: Bei näherer Betrachtung stelle ich fest, dass es sich eher um ein Kernel-spezifisches Problem als um ein fehlerhaftes Kompilieren handelt.

Nun, da war diese Theorie. Erhielt "NICHT ok" für SPL/ZFS 0.6.5.7-1 auf Centos 6.6 (Kernel 2.6.32-642.1.1) in einer VM (mit den {spl,zfs}-dkms-Paketen auf zfsonlinux.org).

@rincebrain
weiß nicht was du mit falsch kompilieren meinst. Wenn es sich um ein Timing-Problem handelt, müssen wir es besser verstehen. Wenn du oder @pwolny veröffentlichen kannst
zdb -ddddd pool/fs-Objekt
Ausgabe für die fraglichen Dateien könnte ich eine bessere Vorstellung von der Art des Problems bekommen.

@bprotopopov Ich meine, ich kann Ihnen die emittierten Sendestreams und die winzigen Dateien, die die Pools unterstützen, übergeben, wenn das von Nutzen wäre.

Wie würden Sie vorschlagen, dass ich den entsprechenden Objektverweis auf die Hand zdb bekomme?

Abgesehen davon, da die gesamte -ddddd-Ausgabe der beiden FSes des Demonstrationspools winzig ist, hänge ich einfach beide an.
test_fs_A.txt
test_fs_B.txt

Und als Bonus ist hier die Sparse-Datei, die den gesamten Pool enthält, aus dem die Ausgabe erfolgt, da die komprimierte Datei nur 2,5 MB groß ist (sie wird in eine 192 MB-sparse-Datei entpackt, die etwa 32 MB belegt).

https://www.dropbox.com/s/ir8b6ot07k420mn/zfs_pool_0.6.5.6-1_A_7s_3.xz

Nur damit andere Leute nicht in den Kaninchenbau gehen, wenn schon jemand anderes dort angekommen ist...

@pcd1193182 kam zu dem Schluss, dass dies "nur" Illumos 6513 ist.

Lassen Sie mich das also etwas erweitern. Der Fix für illumos 6513 wird dieses Problem beheben, jedoch nicht rückwirkend. Mit anderen Worten, alle Pools, die diesen Status bereits aufweisen, werden nicht behoben; Bei solchen Pools sind die Geburtszeiten der Loch-BPs bereits auf Null gesetzt, und zfs hat keine Möglichkeit zu sagen, welche fehlerhaft sind und welche richtig sind. Alle neuen Pools, die nach der Anwendung des Fix erstellt wurden, funktionieren.

Für Leute, die mit ihren alten Pools feststecken, könnte eine Problemumgehung erstellt werden, die im Grunde die Lochgeburt deaktiviert. Idealerweise wäre dies eine abstimmbare, so dass sie selektiv angewendet werden könnte. Auf illumos sieht der Patch so aus: https://gist.github.com/pcd1193182/2c0cd47211f3aee623958b4698836c48 . Ich verstehe, dass das Einstellen von Variablen unter Linux einige Fummelei erfordert. Ob der Standardwert auf TRUE oder FALSE gesetzt wird, überlasse ich anderen.

Am Do, 7. Juli 2016, schrieb Laurentiu Nicola:

Für alle, die sich Sorgen machen, kann dieses Skript helfen, spärliche Dateien zu finden: http://unix.stackexchange.com/a/86446.

Werden die Löcher noch existieren (wenn auch in der falschen Größe) auf dem?
empfangenes Dateisystem, für diejenigen von uns, die unsere Migrationen bereits durchgeführt haben
über 'send|recv' und das Originalmedium verworfen?

Tim Connors

@pcd1193182

Dies ist ein guter Punkt, den Sie im Hinterkopf behalten sollten, ja, die mit fehlerhaftem Code erstellten Snapshots werden nicht durch den korrigierten Code geheilt, da die Blockzeiger auf der Festplatte keine richtigen Geburtsepochen (nicht Null) enthalten.

@pwolny hat jedoch ein Skript veröffentlicht, von dem er behauptet, dass es das Problem mit völlig neuen Pools neu erstellt, die während des Tests erstellt wurden. Ich habe es ausgeführt, konnte das Problem nicht sehen, aber es gibt einen ZDB-Dump über dem neuen Pool mit dem Problem, das ich mir ansehen werde.

Hallo @rincebrain
Mit zdb können Sie Dateisysteme so auflisten, dass Sie sehen können, welche Datei welche dnode-Nummer hat. diese Zahl kann als 'obejct'-Argument verwendet werden, um nur diese Datei zu sichern. Für zvols ist dies einfacher, da das zvol-Objekt (Daten) immer 1 ist, wie ich mich erinnere. Übrigens, dieser Fehler betrifft auch zvols.

OK, ich habe mir die zdb-Ausgabe angesehen und angenommen, dass ich die Notation von @rincebrain richtig interpretiert

Dies führt dazu, dass diese Löcher beim Senden nicht übertragen werden, und daher enthält das Dateisystem auf der Empfangsseite immer noch Daten ungleich Null. Das war das spezifische Szenario, das vom Testskript erstellt wurde.

Hier also meine Empfehlung.

Können @rincebrain und @pwolny bitte das Skript ändern, mit dem das Problem reproduziert wurde
'sync'-Befehle nach jedem dd/truncate/anderen Updates (oder alternativ zumindest vor dem Erstellen von Snapshots), so dass wir einigermaßen sicher sein können, dass dies nicht das Problem mit dem 'Linux-Seiten-Cache' ist?

@bprotopopov Das Skript, das er oben verlinkt hat, ist dasjenige, das ich zum Testen verwendet habe. Der Fehler tritt nicht auf illumos auf, da wir den Fix für illumos 6513 haben. Linux hat diesen Fix noch nicht integriert, sodass jeder, der Trunk oder älteres ZoL verwendet, auf das Problem stoßen wird.

EDIT: Anscheinend irre ich mich; Der Fix ist im Kofferraum, aber noch nicht in einer Version.

Hallo, @pcd1193182
Ich habe das 6513-Fix bereits nach ZoL portiert und es befindet sich ab https://github.com/zfsonlinux/zfs/commit/bc77ba73fec82d37c0b57949ec29edd9aa207677 im Master-Zweig
Ich nahm an, dass die oben erwähnte Version 0.6.5.7 diesen Fix enthält. Wenn nicht :) dann ist das Problem ganz offensichtlich!

Also, @pcd1193182 hat es geschafft :)

@pwolny , @rincebrain , zfs-0.6.5.7 enthält definitiv nicht den Fix für 6513, und deshalb sehen Sie das Problem.

Ein weiteres Rätsel gelöst, denke ich.

eine Anleitung für den Dummy, wie man mit den Folgen umgeht, wird hilfreich sein,

Ich bin ziemlich verwirrt darüber, wie ich mich um mein System kümmern soll,
Ich habe nicht genug Ressourcen, um meinen gesamten Pool herauszuziehen und wiederherzustellen,

Das lässt mich bis zum nächsten Upgrade des Systems nicht mehr herauskommen.

Kurz gesagt, für alle, die einen Pool mit aktiviertem hole_birth haben.

• Wenn Sie von diesem Problem (oder anderen Hole_birth-Problemen) betroffen sind, verhindern die Korrekturen für diese nur das Schreiben weiterer falscher Daten, sie reparieren Ihre vorhandenen Daten nicht.
• Wenn Probleme mit der hole_birth-Funktion bestehen, einschließlich dieses Problems, können Sie so etwas wie den Patch in PR #4833 verwenden, um ZFS anzuweisen, die Daten der hole_birth-Funktion zu ignorieren, und Ihre Sendungen werden korrekt funktionieren.
• Es gibt derzeit keine Möglichkeit, außer einem send|recv zu erkennen und die Daten zu vergleichen, ob Sie betroffene Dateien haben. Das obige Skript von stackexchange wird spärliche Dateien auf der Festplatte bemerken, aber nur weil Sie spärliche Dateien haben, bedeutet das nicht, dass Sie betroffen sind.
• Ich _glaube_, ich habe eine brauchbare Methode, um zu erkennen, ob dieser Fehler eine bestimmte Datei über zwei Snapshots in einem Pool betrifft, und schreibe derzeit ein Proof-of-Concept-Skript, um zu sehen, ob es Bestand hat. Da es ungefähr (Anzahl der Dateien in Ihrem Dataset * Anzahl der Snapshots, die Sie überprüfen) Lookups pro Dataset erfordert, um dies zu bestimmen, wird es nicht das schnellste Ding aller Zeiten sein, aber wenn es funktioniert, vermute ich, dass dies ein akzeptabler Kompromiss ist Leute, die es wissen möchten.

@rincebrain

Ich habe eine Frage,

Kann ich diese spärlichen Dateien nach Patch #4754 einfach neu schreiben oder eine Kopie erstellen, um sie von Hole-Geburt-Problemen zu befreien?

@AndCycle Sie müssten etwas wie cp foo foo_1 && mv foo_1 foo tun, und dies würde es in keinem Ihrer Schnappschüsse beheben. Wenn Sie #4833 angewendet und die Tunable ignore_hole_birth aktiviert haben, dann sollte ein send|recv die resultierende Kopie nicht diesen speziellen Fehler aufweisen.

Ich würde wahrscheinlich warten, bis illumos #7176 einen Fix verfügbar + zusammengeführt hat, um die Mühe zu machen.

@rincebrain danke für deine ausführliche Erklärung, es sieht so aus, als ob es noch weitere

Wir erhalten bc77ba7 aus dem Master-Zweig für 0.6.5.8.

Empfehle auch Abholung

https://github.com/zfsonlinux/zfs/commit/463a8cfe2b293934edd2ee79115b20c4598353d6

[https://2.gravatar.com/avatar/8102cb4a97c5b057b8f2cab11480bd81?d=https%3A%2F%2Fassets-cdn.github.com%2Fimages%2Fgravatars%2Fgravatar-user-420.png&r=x&s=200] https:/ /github.com/zfsonlinux/zfs/commit/463a8cfe2b293934edd2ee79115b20c4598353d6

Illumos 6844 - dnode_next_offset kann fiktive Löcher erkennen · zfsonlinux/ zfs@463a8cfhttps ://github.com/zfsonlinux/zfs/commit/463a8cfe2b293934edd2ee79115b20c4598353d6
github.com
6844 dnode_next_offset kann fiktive Löcher erkennen Bewertet von: Matthew Ahrens Bewertet von: George Wilson Bewertet von: Brian Behlendorf

Von: Brian Behlendorf [email protected]
Gesendet: Dienstag, 12. Juli 2016 12:49:12
An: zfsonlinux/zfs
Cc: Boris Protopopov; Erwähnen
Betreff: Re: [zfsonlinux/zfs] Unbemerkt beschädigte Datei in Snapshots nach dem Senden/Empfangen (#4809)

Wir erhalten bc77ba7 https://github.com/zfsonlinux/zfs/commit/bc77ba73fec82d37c0b57949ec29edd9aa207677 aus dem Master-Zweig für 0.6.5.8.

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie auf diese E - Mail direkt, sehen sie auf Gi tHubhttps: //github.com/zfsonlinux/zfs/issues/4809#issuecomment -232.106.427 oder stumm schalten die th readhttps: //github.com/notifications/unsubscribe/ACX4uQ-OHIe- aowRR6uO8loA4ZJ_fwx1ks5qU8WIgaJpZM4I-nnL.

Ich habe etwas Zeit gefunden, um den Test abzuschließen.

Es scheint, dass ich mit ZFS 0.6.5-329_g5c27b29 und SPL 0.6.5-63_g5ad98ad ein anderes Verhalten erhalte, wenn ich den Pool mit der ursprünglichen problematischen Datei sende/empfange ("/nas1FS/backup/.zfs/snapshot/20160618/samba_share/a /home/bak/aa/wx/wxWidgets-2.8.12/additions/lib/vc_lib/wxmsw28ud_propgrid.pdb") und den mit dem Testskript generierten Pool.

• "largefile" aus dem mit dem Testskript erstellten Pool scheint korrekt zu übertragen, wenn der getestete Pool auf der neuen Version von zfs/spl erstellt und übertragen wurde
• "largefile" aus dem Testpool scheint mit falschen Prüfsummen zu übertragen, wenn der getestete Pool auf der alten Version von zfs/spl erstellt und auf der neuen Version von zfs/spl übertragen wurde, "zdb -ddddd" Ausgabe von ZFS 0.6.5 -329_g5c27b29 mit angehängten md5sums:
  zdb_ddddd_out.nas1FS.test_fs.20160629_3.largefile.txt
  zdb_ddddd_out.nas1FS.test_fs_target.20160629_3.largefile.txt
• die Datei, die diesen Fehlerbericht gestartet hat, wird korrekt mit send/receive auf die neue Version von zfs/spl übertragen, "zdb -ddddd"-Ausgabe von ZFS 0.6.5-329_g5c27b29 mit angehängten md5sums:
  zdb_ddddd_out.nas1FS.20160306_1.wxmsw28ud_propgrid.pdb.txt
  zdb_ddddd_out.backup_raidz_test.20160306_1.wxmsw28ud_propgrid.pdb.txt

Das Symptom des ursprünglichen Problems scheint sich also mit ZFS 0.6.5-329_g5c27b29 und SPL 0.6.5-63_g5ad98ad von selbst gelöst zu haben. Das ist etwas verblüffend.

Vielleicht sind dies jetzt überflüssige Informationen, aber ich habe zfs-Versionen gefunden, wenn das Testskript das Verhalten ändert und mir leicht unterschiedliche Ausgaben liefert.
Mit "zfs 0.6.4-53 - 3df293404a102398445fc013b67250073db9004e - Typkonflikt auf 32-Bit-Systemen beheben" erhalte ich "test_matrix_output.txt":

oooooEEEEEE
oooooEEEEEE
oooooEEEEEE
oooooEEEEEE

mit "zfs 0.6.4-54 – f1512ee61e2f22186ac16481a09d86112b2d6788 - Illumos 5027 - zfs Large Block support" bekomme ich "test_matrix_output.txt":

oooooEEEEEE
oooooEEEEEE
oooooEEEEEE
oooooEEEEEE

(In der obigen Matrix nimmt die Schlafzeit von links nach rechts zu und die Poolgröße nimmt von oben nach unten zu)

@bprotopopov Ich habe auch mit Synchronisierungsbefehlen getestet, die dem

Übrigens gibt es eine einfachere Methode, um eine ID einer einzelnen Datei für zdb zu erhalten, als so etwas zu tun:
zdb -dddd nas1FS/backup |grep -e "ZFS plain file" -e "path" | grep "home/bak/aa/wx/wxWidgets-2.8.12/additions/lib/vc_lib/wxmsw28ud_propgrid.pdb" -B 5
Entschuldigung, dass ich das hier frage, aber vielleicht übersehe ich etwas Offensichtliches?

Danke für die Hilfe, ich schätze wirklich all die Arbeit, die in das zfsonlinux gesteckt wurde.

Hallo @pwolny ,

Entschuldigung, ich kenne keinen einfacheren Weg, die Dnode-Nummer zu finden, als in der ZDB-Ausgabe nach dem Namen zu suchen. Mir ist jedoch aufgefallen, dass die erste dnode-Nummer in ZFS-Dateisystemen, die regulären Dateien zugewiesen wird, 7 ist. Wenn Sie also eine Datei in einem Dateisystem haben, ist es #7. Wenn Sie die Reihenfolge der Dateierstellung kennen, lauten die nachfolgenden Dnode-Nummern 8, 9, ...

Ich gebe zu, dass ich der Beschreibung der Testergebnisse in Ihrer Nachricht nicht ganz folgen kann. Verstehe ich das richtig, dass die vom Code mit dem Fix für die Metadatenlöcher (illumos 6315) erstellten Datensätze in Ordnung sind, wenn sie mit zfs send übertragen werden (mit oder ohne Fix, egal), aber Datensätze, die vom Code erstellt wurden ohne eine solche Korrektur Fehler anzeigen (wiederum bei der Übertragung mit einer der beiden Codeversionen)? Das ist zu erwarten, da sich der Fehler in den Daten auf der Festplatte widerspiegelt, nicht im ZFS-Sendecode - wenn die Daten einmal falsch geschrieben wurden, dann deaktivieren Sie die Hole_birth-Optimierung (der Patch mit dem zuvor in diesem Thread besprochenen Tunable) ), wird zfs send die Löcher nicht richtig übertragen.

Ist das der dritte Fall, den Sie beschreiben? Dass Sie mit dem Patch, der die hole_birth-Optimierung deaktiviert hat, defekte On-Disk-Daten korrekt übertragen konnten? Wenn ja, ist dies wie erwartet.

Boris.

Von: pwolny [email protected]
Gesendet: Dienstag, 12. Juli 2016 20:10:43
An: zfsonlinux/zfs
Cc: Boris Protopopov; Erwähnen
Betreff: Re: [zfsonlinux/zfs] Unbemerkt beschädigte Datei in Snapshots nach dem Senden/Empfangen (#4809)

Ich habe etwas Zeit gefunden, um den Test abzuschließen.

Es scheint, dass ich mit ZFS 0.6.5-329_g5c27b29 und SPL 0.6.5-63_g5ad98ad ein anderes Verhalten erhalte, wenn ich den Pool mit der ursprünglichen problematischen Datei sende/empfange ("/nas1FS/backup/.zfs/snapshot/20160618/samba_share/a /home/bak/aa/wx/wxWidgets-2.8.12/additions/lib/vc_lib/wxmsw28ud_propgrid.pdb") und den mit dem Testskript generierten Pool.

• "largefile" aus dem mit dem Testskript erstellten Pool scheint korrekt zu übertragen, wenn der getestete Pool auf der neuen Version von zfs/spl erstellt und übertragen wurde
• "largefile" aus dem Testpool scheint mit falschen Prüfsummen zu übertragen, wenn der getestete Pool auf der alten Version von zfs/spl erstellt und auf der neuen Version von zfs/spl übertragen wurde, "zdb -ddddd" Ausgabe von ZFS 0.6.5 -329_g5c27b29 mit angehängten md5sums:
  zdb_ddddd_out.nas1FS.test_fs.20160629_3.largefile. txthttps://github.com/zfsonlinux/zfs/files/360425/zdb_ddddd_out.nas1FS.test_fs.20160629_3.largefile.txt
  zdb_ddddd_out.nas1FS.test_fs_target.20160629_3.largefile. txthttps://github.com/zfsonlinux/zfs/files/360426/zdb_ddddd_out.nas1FS.test_fs_target.20160629_3.largefile.txt
• die Datei, die diesen Fehlerbericht gestartet hat, wird korrekt mit send/receive auf die neue Version von zfs/spl übertragen, "zdb -ddddd"-Ausgabe von ZFS 0.6.5-329_g5c27b29 mit angehängten md5sums:
  zdb_ddddd_out.nas1FS.20160306_1.wxmsw28ud_propgrid.pdb. txthttps://github.com/zfsonlinux/zfs/files/360418/zdb_ddddd_out.nas1FS.20160306_1.wxmsw28ud_propgrid.pdb.txt
  zdb_ddddd_out.backup_raidz_test.20160306_1.wxmsw28ud_propgrid.pdb. txthttps://github.com/zfsonlinux/zfs/files/360419/zdb_ddddd_out.backup_raidz_test.20160306_1.wxmsw28ud_propgrid.pdb.txt

Das Symptom des ursprünglichen Problems scheint sich also mit ZFS 0.6.5-329_g5c27b29 und SPL 0.6.5-63_g5ad98ad von selbst gelöst zu haben. Das ist etwas verblüffend.

Vielleicht sind dies jetzt überflüssige Informationen, aber ich habe zfs-Versionen gefunden, wenn das Testskript das Verhalten ändert und mir leicht unterschiedliche Ausgaben liefert.
mit "zfs 0.6.4-53 - 3df2934 https://github.com/zfsonlinux/zfs/commit/3df293404a102398445fc013b67250073db9004e - Typkonflikt auf 32-Bit-Systemen behoben" bekomme ich "test_matrix_output.txt":

oooooEEEEEE
oooooEEEEEE
oooooEEEEEE
oooooEEEEEE
oooooEEEEEE

mit "zfs 0.6.4-54 - f1512 eehttps://github.com/zfsonlinux/zfs/commit/f1512ee61e2f22186ac16481a09d86112b2d6788 - Illumos 5027 - zfs Large Block support" bekomme ich "test_matrix_output.txt":

EEEEEEEEEEE
oooooEEEEEE
oooooEEEEEE
oooooEEEEEE
oooooEEEEEE

(In der obigen Matrix nimmt die Schlafzeit von links nach rechts zu und die Poolgröße nimmt von oben nach unten zu)

@bprotop opovhttps://github.com/bprotopopov Ich habe auch mit Sync-Befehlen getestet, die dem

Übrigens gibt es eine einfachere Methode, um eine ID einer einzelnen Datei für zdb zu erhalten, als so etwas zu tun:
zdb -dddd nas1FS/backup |grep -e "ZFS-Klardatei" -e "Pfad" | grep "home/bak/aa/wx/wxWidgets-2.8.12/additions/lib/vc_lib/wxmsw28ud_propgrid.pdb" -B 5
Entschuldigung, dass ich das hier frage, aber vielleicht übersehe ich etwas Offensichtliches?

Danke für die Hilfe, ich schätze wirklich all die Arbeit, die in das zfsonlinux gesteckt wurde.

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie auf diese E - Mail direkt, sehen sie auf Gi tHubhttps: //github.com/zfsonlinux/zfs/issues/4809#issuecomment -232.218.861 oder stumm schalten die th readhttps: //github.com/notifications/unsubscribe/ACX4uQqvLzbatZTuwO-rZH0CF- 960t8jks5qVC0DgaJpZM4I-nnL.

@pwolny zumindest in der Zufallsstichprobe, um zu bestätigen, Objekt-ID <=> was in stat() und Freunden als "Inode-Nummer" gemeldet wird, also könnten Sie einfach die Ausgabe von "stat [Pfad zur Datei]" analysieren oder einen von aufrufen die stat-Funktionsfamilie.

Oder meintest du etwas anderes mit deiner Frage?

Nun, das ist ein guter Punkt - sollte im Code leicht zu erkennen sein, wenn es beabsichtigt ist.

Tippfehler mit freundlicher Genehmigung von meinem iPhone

Am 12. Juli 2016 um 21:14 Uhr schrieb Rich Ercolani < [email protected] [email protected] >:

@pw olnyhttps: //github.com/pwolny zumindest in Stichproben , um zu bestätigen, Objekt - ID <=> , was als „Inode - Nummer“ in stat gemeldet wird () und Freunde, so dass Sie nur die Ausgabe von „Statistik nicht analysieren [ path to file]" oder rufen Sie eine der stat-Funktionen auf.

Oder meintest du etwas anderes mit deiner Frage?

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie auf diese E - Mail direkt, sehen sie auf Gi tHubhttps: //github.com/zfsonlinux/zfs/issues/4809#issuecomment -232.228.087 oder stumm schalten die th readhttps: //github.com/notifications/unsubscribe/ACX4ue8dFlnm8NwKHSdjSFbhQnO48OwJks5qVDvkgaJpZM4I-nnL.

Jawohl! Danke für den Einblick in den Stat-Befehl. Es war genau das, was ich gesucht habe.

@bprotopopov
Entschuldigung, ich werde versuchen zu klären.
Bisher bin ich davon ausgegangen, dass die Datei "wxmsw28ud_propgrid.pdb" das gleiche zugrunde liegende Problem (hole_birth bug) hatte wie die Dateien, die vom Testskript generiert wurden.
Vor kurzem habe ich dieselbe Version von zfs (ZFS 0.6.5-329_g5c27b29 und SPL 0.6.5-63_g5ad98ad) verwendet, um drei Pools zu übertragen:

• Testpool generiert mit älterer (defekter) Version von zfs => Prüfsummen-Mismatch
• Testpool generiert mit neuer (ok) Version von zfs => habe eine ok Prüfsumme erhalten
• Original-Pool mit der Datei "wxmsw28ud_propgrid.pdb", von der auch angenommen wurde, dass sie defekt ist => habe eine ok Prüfsumme erhalten (das habe ich nicht erwartet)

Ich habe keine Patches angewendet, die die Hole_birth-Optimierung deaktivieren, zumindest meines Wissens.
Der mit einer älteren (defekten) Version von zfs generierte Testpool wurde falsch übertragen (mit zfs 0.6.5-329_g5c27b29), so dass ich davon ausgegangen bin, dass diese Optimierung nicht vorhanden war.
Liege ich in dieser Annahme falsch?

Ich verstehe. Es gab zwei Fehler, Illumos 6513 und 6370, und die zfs-Version, die Sie zum Senden/Recv verwenden, hat den letzteren Fehler behoben. Dies ist wahrscheinlich der Grund für den positiven Testfall, nach dem Sie fragen.

Boris.

Von: pwolny [email protected]
Gesendet: Mittwoch, 13. Juli 2016 16:17:49
An: zfsonlinux/zfs
Cc: Boris Protopopov; Erwähnen
Betreff: Re: [zfsonlinux/zfs] Unbemerkt beschädigte Datei in Snapshots nach dem Senden/Empfangen (#4809)

Jawohl! Danke für den Einblick in den Stat-Befehl. Es war genau das, was ich gesucht habe.

@bprotopopovhttps://github.com/bprotopopov
Entschuldigung, ich werde versuchen zu klären.
Bisher bin ich davon ausgegangen, dass die Datei "wxmsw28ud_propgrid.pdb" das gleiche zugrunde liegende Problem (hole_birth bug) hatte wie die Dateien, die vom Testskript generiert wurden.
Vor kurzem habe ich dieselbe Version von zfs (ZFS 0.6.5-329_g5c27b29 und SPL 0.6.5-63_g5ad98ad) verwendet, um drei Pools zu übertragen:

• Testpool generiert mit älterer (defekter) Version von zfs => Prüfsummen-Mismatch
• Testpool generiert mit neuer (ok) Version von zfs => habe eine ok Prüfsumme erhalten
• Original-Pool mit der Datei "wxmsw28ud_propgrid.pdb", von der auch angenommen wurde, dass sie defekt ist => habe eine ok Prüfsumme erhalten (das habe ich nicht erwartet)

Ich habe keine Patches angewendet, die die Hole_birth-Optimierung deaktivieren, zumindest meines Wissens.
Der mit einer älteren (defekten) Version von zfs generierte Testpool wurde falsch übertragen (mit zfs 0.6.5-329_g5c27b29), so dass ich davon ausgegangen bin, dass diese Optimierung nicht vorhanden war.
Liege ich in dieser Annahme falsch?

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf Gi tHub anhttps://github.com/zfsonlinux/zfs/issues/4809#issuecomment -232473828, oder schalten Sie das nnL.

Mein Upgrade-Pfad für zfs war v0.6.5.3 -> 0.6.5.7 -> 0.6.5-329_g5c27b29.
Ich habe den Testpool (der eine defekte Prüfsumme ergibt) und den Originalpool (der die Datei "wxmsw28ud_propgrid.pdb" enthält) auf v0.6.5.3 erstellt. Ich habe sie beide während der Upgrades auf dem ursprünglichen Festplattensatz behalten und habe versucht, sie auf eine neue Festplatte zu übertragen. Die Erstellung dieser Pools und Dateien erfolgte in v0.6.5.3, daher nahm ich an, dass die Daten auf der Festplatte beschädigt waren.
Wenn ich mich nicht irre, erschien der Illumos 6513- und 6370-Patch irgendwann nach zfs v0.6.5.5, also würde ich immer noch erwarten, dass ich bei der Übertragung mit zfs 0.6.5-329_g5c27b29 eine Fehlerprüfsumme in der Datei "wxmsw28ud_propgrid.pdb" bekomme?

329 enthält den Fix für 6370

Tippfehler mit freundlicher Genehmigung von meinem iPhone

Am 13. Juli 2016 um 18:34 Uhr schrieb pwolny < [email protected] [email protected] >:

Mein Upgrade-Pfad für zfs war v0.6.5.3 -> 0.6.5.7 -> 0.6.5-329_g5c27b29.
Ich habe den Testpool (der eine defekte Prüfsumme ergibt) und den Originalpool (der die Datei "wxmsw28ud_propgrid.pdb" enthält) auf v0.6.5.3 erstellt. Ich habe sie beide während der Upgrades auf dem ursprünglichen Festplattensatz behalten und habe versucht, sie auf eine neue Festplatte zu übertragen. Die Erstellung dieser Pools und Dateien erfolgte in v0.6.5.3, daher nahm ich an, dass die Daten auf der Festplatte beschädigt waren.
Wenn ich mich nicht irre, erschien der Illumos 6513- und 6370-Patch irgendwann nach zfs v0.6.5.5, also würde ich immer noch erwarten, dass ich bei der Übertragung mit zfs 0.6.5-329_g5c27b29 eine Fehlerprüfsumme in der Datei "wxmsw28ud_propgrid.pdb" bekomme?

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie auf diese E - Mail direkt, sehen sie auf Gi tHubhttps: //github.com/zfsonlinux/zfs/issues/4809#issuecomment -232.506.807 oder stumm schalten die th readhttps: //github.com/notifications/unsubscribe/ACX4ub983QxeqRK85tPzaibLhiJvLjjfks5qVWfzgaJpZM4I-nnL.

Ok, das heißt also, dass der 6370-Fehler nachträglich behoben werden kann und nicht mit beschädigten Daten auf der Festplatte zusammenhängt?
Wenn ja, würde das sicherlich das beobachtete Verhalten erklären und dieses Problem für mich lösen.
Danke für alle Erklärungen, das hat mich wirklich aufgeklärt.

Hallo, ich teste dieses Problem mit den folgenden Patches basierend auf 0.6.5.7, es gibt immer noch md5-Mismatch-Probleme.

1. 6513
2. Illumos 6844
3. Illumos 6370 bereits in 0.6.5.7 . gepatcht

Ich bin mir nicht sicher, ob ich Patches verpasst habe, wenn ja, lassen Sie es mich bitte wissen.
Ich habe das oben erwähnte Testskript wie folgt geändert und scheint dieses Problem mit der Nichtübereinstimmung leichter zu beheben.

#!/bin/bash
# cat zfs_hole_transmit_test.sh, modified by neil for testing

function zfs_snap_send_recv()
{
    zfs create -o recordsize=4k p1/hb
    zfs set compression=lz4 p1/hb
    truncate -s 1G /p1/hb/large_file
    #ls /p1/hb/large_file -als
    dd if=/dev/urandom of=/p1/hb/large_file bs=4k count=$((($RANDOM%100+3)*128)) seek=$((($RANDOM%100+1)*128)) 2> /dev/null
    zfs snapshot p1/hb@$test_count"_1"
    truncate -s $((($RANDOM%10+2)*128*4*1024)) /p1/hb/large_file
    dd if=/dev/urandom of=/p1/hb/large_file bs=4k count=$(($RANDOM%100+128)) seek=$((3*128)) conv=notrunc 2> /dev/null
    dd if=/dev/urandom of=/p1/hb/large_file bs=4k count=10 seek=$((($RANDOM%10+2)*128)) conv=notrunc 2> /dev/null
    zfs snapshot p1/hb@$test_count"_2"
    zfs send p1/hb@$test_count"_1" | zfs recv p1/backup
    zfs send -i p1/hb@$test_count"_1" p1/hb@$test_count"_2" | zfs recv p1/backup
}

function checkmd5()
{
    origin_md5=$(md5sum /p1/hb/large_file | awk '{print $1}')
    backup_md5=$(md5sum /p1/backup/large_file | awk '{print $1}')
    #echo $origin_md5 $backup_md5
    if [ "$origin_md5" = "$backup_md5" ]; then
        echo "MD5 match, $origin_md5, $backup_md5"
    else
        echo "MD5 mismatch, hole birth found, exit"
        echo "$origin_md5 /p1/hb/large_file"
        echo "$backup_md5 /p1/backup/large_file"
        exit 1
    fi
}
function zfs_clean()
{
    zfs destroy p1/backup -r
    zfs destroy p1/hb -r
}

zfs_clean
test_count=1
while true
do
    echo "Test count:$test_count"
    zfs_snap_send_recv
    checkmd5
    zfs_clean
    test_count=$(($test_count+1))
    #sleep 1
done

weitere Informationen, bitte lass es mich wissen.

Hallo Neil
Bitte überprüfen Sie Ihr Testverfahren, die Modulversionen usw.

Tippfehler mit freundlicher Genehmigung von meinem iPhone

Am 18. Juli 2016 um 21:06 Uhr schrieb Neil < [email protected] [email protected] >:

Hallo, ich teste dieses Problem mit den folgenden Patches basierend auf 0.6.5.7, es gibt immer noch md5-Mismatch-Probleme.

1. 6513 https://github.com/zfsonlinux/zfs/commit/bc77ba73fec82d37c0b57949ec29edd9aa207677
2. Illumos 6844 https://github.com/zfsonlinux/zfs/commit/463a8cfe2b293934edd2ee79115b20c4598353d6
3. Illumos 6370 https://github.com/illumos/illumos-gate/commit/286ef71 bereits gepatcht in 0.6.5.7

Ich bin mir nicht sicher, ob ich Patches verpasst habe, wenn ja, lassen Sie es mich bitte wissen.
Ich habe das oben erwähnte Testskript wie folgt geändert und scheint dieses Problem mit der Nichtübereinstimmung leichter zu beheben.

!/bin/bash

Katze zfs_hole_transmit_test.sh, modifiziert von Neil zum Testen

Funktion zfs_snap_send_recv()
{
zfs create -o recordsize=4k p1/hb
zfs setkompression=lz4 p1/hb
kürzen -s 1G /p1/hb/large_file
#ls /p1/hb/large_file -als
dd if=/dev/urandom of=/p1/hb/large_file bs=4k count=$((($RANDOM%100+3)_128)) seek=$((($RANDOM%100+1)_128)) 2> /dev/null
zfs-Schnappschuss p1/hb@$test_count"_1"
abschneiden -s $((($RANDOM%10+2)_128_4_1024)) /p1/hb/large_file
dd if=/dev/urandom of=/p1/hb/large_file bs=4k count=$(($RANDOM%100+128)) seek=$((3_128)) conv=notrunc 2> /dev/null
dd if=/dev/urandom of=/p1/hb/large_file bs=4k count=10 seek=$((($RANDOM%10+2)*128)) conv=notrunc 2> /dev/null
zfs-Snapshot p1/hb@$test_count"_2"
zfs sende p1/hb@$test_count"_1" | zfs recv p1/backup
zfs send -i p1/hb@$test_count"_1" p1/hb@$test_count"_2" | zfs recv p1/backup
}

Funktion checkmd5()
{
origin_md5=$(md5sum /p1/hb/large_file | awk '{print $1}')
backup_md5=$(md5sum /p1/backup/large_file | awk '{print $1}')
#echo $origin_md5 $backup_md5
if [ "$origin_md5" = "$backup_md5" ]; dann
echo "MD5-Übereinstimmung, $origin_md5, $backup_md5"
anders
echo "MD5-Mismatch, Lochgeburt gefunden, Exit"
echo "$origin_md5 /p1/hb/large_file"
echo "$backup_md5 /p1/backup/large_file"
Ausgang 1
fi
}
Funktion zfs_clean()
{
zfs zerstören p1/backup -r
zfs zerstören p1/hb -r
}

zfs_clean
test_count=1
während wahr
tun
echo "Testzähler:$test_count"
zfs_snap_send_recv
checkmd5
zfs_clean
test_count=$(($test_count+1))
#schlafen 1
getan

weitere Informationen, bitte lass es mich wissen.

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf Gi tHub anhttps://github.com/zfsonlinux/zfs/issues/4809#issuecomment -233503399, oder schalten Sie das nnL.

Hallo Boris

Diese Testprozedur wiederholte den gleichen Poolerstellungs-/Dateierstellungs-/Snapshot-/Übertragungszyklus im Skript.
Erstellen Sie den Pool neben der Datensatzeinstellung im Skript mit:

zpool create p1 sdb -f -o ashift=12 -o autoexpand=on
zpool set listsnapshots=on p1

Und die Testumgebung & Modulversion:

• ubuntu16.04 (linux-4.4.0-31-generisch)
• spl-Version: 0.6.5.7
• zfs-Version: 0.6.5.7-1 (Patch mit 6513, Illumos 6844)

Ich konnte die beschädigten Dateien nicht hochladen.
Datei beschädigt bei 0030 0000 - 003F FFFF, Daten in hb/large_file sind alle Nullen und in backup/large_files gibt es beschädigte Daten.

Wie ich getestet habe, wurden mindestens 2 Nichtübereinstimmungen gefunden. Es wird mit mehr Test ausgesetzt.
Wenn ich keine Patches verpasst habe, sollte dieses Problem weiterhin bestehen und noch nicht vollständig behoben sein.
Abgesehen davon, hole_birth (https://github.com/zfsonlinux/zfs/pull/4833) zu ignorieren, habe ich jetzt keine Idee für dieses Problem.
Ich freue mich, dieses Problem zu beheben, wenn Sie Hilfe benötigen.

Neil, der Grund, warum Sie nach dem Verfahren gefragt haben, war, dass ich definitiv mein ursprüngliches Skript sowie die Skripte im früheren verwandten Thread ausgeführt habe und keine Probleme festgestellt habe, wenn der Build den Fix für 6513 enthielt.

Bitte fügen Sie das Git-Log Ihres Repositorys, in dem Sie ZFS erstellt haben, und die Ausgabe der Befehle an

cat /sys/modules/zfs/version

cat /sys/modules/spl/version

Auf Ihrem System, auf dem Ihre Tests fehlgeschlagen sind (ich gehe natürlich davon aus, dass immer noch dieselbe Version von ZFS/SPL ausgeführt wird).

Boris.

Tippfehler mit freundlicher Genehmigung von meinem iPhone

Am 18. Juli 2016 um 22:56 Uhr schrieb Neil < [email protected] [email protected] >:

Hallo Boris

Diese Testprozedur wiederholte den gleichen Poolerstellungs-/Dateierstellungs-/Snapshot-/Übertragungszyklus im Skript.
Erstellen Sie den Pool neben der Datensatzeinstellung im Skript mit:

zpool create p1 sdb -f -o ashift=12 -o autoexpand=on
zpool setlistsnapshots=on p1

Und die Testumgebung & Modulversion:

• ubuntu16.04 (linux-4.4.0-31-generisch)
• spl-Version: 0.6.5.7
• zfs-Version: 0.6.5.7-1 (Patch mit 6513, Illumos 6844)

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie auf diese E - Mail direkt, sehen sie auf Gi tHubhttps: //github.com/zfsonlinux/zfs/issues/4809#issuecomment -233.517.209 oder stumm schalten die th readhttps: //github.com/notifications/unsubscribe-auth/ACX4uVfU6qtFl85F- GBjh2EJn3qdsT3aks5qXDzwgaJpZM4I-nnL.

Boris,
git log von spl und zfs, gitlog.zip
und Versionen
root@i-mruehtn9 :~# cat /sys/module/zfs/version
0.6.5.7-1
root@i-mruehtn9 :~# cat /sys/module/spl/version
0.6.5.7-1

Bestätigt, mit einer Verzögerung von 7 Sekunden zwischen zwei Schreibvorgängen
https://gist.github.com/Georgiy-Tugai/b7ae09767527d111ffb9f0a91b3e3bc4

Arch Linux x86-64, linux-lts 4.4.15-1 , zfs-dkms 0.6.5.7-1 , getestet in einem Pool in einer 3G-Datei auf tmpfs .

Seltsamerweise scheinen spärliche Dateien in meinen Produktionsdaten, die einmal gesendet/empfangen wurden (von einem fast jungfräulichen Pool zu einem anderen jungfräulichen Pool, beide mit allen aktivierten Funktionen), soweit ich das beurteilen kann, intakt.

Ich würde mich über Empfehlungen zur Milderung der Auswirkungen dieses Fehlers freuen; Soll ich den Pool mit deaktiviertem hole_birth neu erstellen?

Ich habe auch mit dem neuesten Master-Zweig getestet und es kann immer noch innerhalb von 0 bis 6 Stunden reproduziert werden.
master-Zweig hat die oben genannten Patches bereits zusammengeführt.
Daher müssen wir uns neben dem Deaktivieren von hole_birth auf dieses Problem konzentrieren.

Um euch zu helfen,

Sie müssen das Build- / Testverfahren befolgen, das ich zuvor in diesem Thread beschrieben habe. Ich kann Ihnen bei der Durchführung der von mir beschriebenen Schritte helfen, wenn Sie Hilfe benötigen, aber ich benötige die angeforderten Informationen.

Ich muss sicher sein, dass Sie das ausführen, was Sie denken, dass Sie laufen.

Boris.

Von: Georgiy Tugai [email protected]
Gesendet: Donnerstag, 21. Juli 2016 11:04:33
An: zfsonlinux/zfs
Cc: Boris Protopopov; Erwähnen
Betreff: Re: [zfsonlinux/zfs] Unbemerkt beschädigte Datei in Snapshots nach dem Senden/Empfangen (#4809)

Bestätigt, mit einer Verzögerung von 7 Sekunden zwischen zwei Schreibvorgängen
https://gist.github.com/Georgiy-Tugai/b7ae09767527d111ffb9f0a91b3e3bc4

Arch Linux x86-64, linux-lts 4.4.15-1, zfs-dkms 0.6.5.7-1, getestet in einem Pool in einer 3G-Datei auf tmpfs.

Seltsamerweise scheinen spärliche Dateien in meinen Produktionsdaten, die einmal gesendet/empfangen wurden (von einem fast jungfräulichen Pool zu einem anderen jungfräulichen Pool, beide mit allen aktivierten Funktionen), soweit ich das beurteilen kann, intakt.

Ich würde mich über Empfehlungen zur Milderung der Auswirkungen dieses Fehlers freuen; sollte ich den Pool neu erstellen, wenn hole_birth deaktiviert ist?

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf Gi tHub anhttps://github.com/zfsonlinux/zfs/issues/4809#issuecomment -234282491, oder schalten Sie das nnL.

Neil,

Bitte geben Sie die von mir zuvor angeforderten Informationen für die Testumgebung an, die den Master-Zweig verwendet.

Mit freundlichen Grüßen,

Boris.

Von: Neil [email protected]
Gesendet: Donnerstag, 21. Juli 2016 12:43:16
An: zfsonlinux/zfs
Cc: Boris Protopopov; Erwähnen
Betreff: Re: [zfsonlinux/zfs] Unbemerkt beschädigte Datei in Snapshots nach dem Senden/Empfangen (#4809)

Ich habe auch mit dem neuesten Master-Zweig getestet und es kann immer noch innerhalb von 0 bis 6 Stunden reproduziert werden.
master-Zweig hat die oben genannten Patches bereits zusammengeführt.
Daher müssen wir uns neben dem Deaktivieren von hole_birth auf dieses Problem konzentrieren.

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf Gi tHub anhttps://github.com/zfsonlinux/zfs/issues/4809#issuecomment -234312294, oder schalten Sie das nnL.

Hallo @pwolny ,

Könnten Sie mir bitte mitteilen, ob Sie immer noch Probleme mit verpassten Löchern für 0.6.5.7 sehen, die durch die Fixes für illumos-6513 und illumos-6844 ergänzt wurden?

Ich sehe, dass @loyou und @Georgiy-Tugai darauf hindeuten, dass es immer noch Bedenken gibt, aber ich konnte bisher nicht bestätigen, dass sie tatsächlich den richtigen Code ausführen.

@bprotopopov , Entschuldigung, dass

spl&zfs git log

und Versionen
root@i-5mbc9uue :~/zfs_sf# cat /sys/module/zfs/version
0.6.5-329_g5c27b29
root@i-5mbc9uue :~/zfs_sf# cat /sys/module/spl/version
0.6.5-63_g5ad98ad

zu der Frage:

Sie müssen das Build-/Testverfahren befolgen, das ich zuvor in diesem Thread beschrieben habe

Ich baue die spl&zfs mit ./autogen.sh && ./configure && make && make install
Ich teste mit dem oben erwähnten Skript, das modifiziert wird, um ein Dateisystem zu erstellen, einen Snapshot zu erstellen, eine Datei zu erstellen, mit zufälliger Größe zu kürzen, mit dd zu ändern, einen Snapshot zu erstellen und dann recv zu senden. Und Schleife dabei.

@loyou

Können Sie bitte Folgendes tun - in Ihrem Skript loggen Sie bitte die zufälligen Offsets und Zählungen ein, die Sie generieren. Wenn Sie dann den Fehler sehen, nehmen Sie diese Offsets und Zählungen und fügen Sie sie in Ihr Skript ein.

Mein ursprüngliches Skript, das mehrmals modifiziert wurde, erzeugte ein Loch, das eine L1-Region bedeckte, und verwendete dafür eine Kombination aus Schreibvorgängen und Trunkierungen. Dann wurde dieses Loch der Größe L1 teilweise überschrieben, und der Fehler (zfs send weiß nicht, dass die restlichen L0-Löcher in den L1-Bereichen _neu_ sind und übertragen werden müssen) wurde ausgelöst.

Dieser Fehler war völlig deterministisch und es war kein Zufall erforderlich. Wenn Sie den Fehler mit bestimmten Offsets sehen, können Sie ihn zu 100 % reproduzieren, einschließlich des ersten Versuchs.

Wenn Sie diese reproduzieren können, veröffentlichen Sie bitte das nicht zufällige Skript. Wenn Sie es nicht können, haben Sie es vielleicht mit etwas anderem zu tun.

Hallo @loyou
nein das ist eine gute Info, dein Testverfahren ist OK.
Folgendes wäre nützlich: Wenn Sie die Offsets/Größen protokolliert haben, schneiden Sie Grenzen in Ihrem Skript ab und wenn Sie das Skript so geändert haben, dass es bei Fehlern stoppt und nicht aufräumt (was es anscheinend bereits tut).

Dann könntest du das verwenden
#zdb -ddddd pool/fs object

wie oben besprochen, um die Blockzeiger auszugeben.

Können Sie der Vollständigkeit halber das unveränderte Originalskript ausführen, das ich verwendet habe (auch oben gezeigt), um zu sehen, ob Sie das 6513-Problem auf sehr einfache Weise reproduzieren können?

zfs create -o recordsize=4k tpool/test_fs
zfs set compression=on tpool/test_fs
truncate -s 1G /tpool/test_fs/large_file
dd if=/dev/urandom of=/tpool/test_fs/large_file bs=4k count=$((3*128)) seek=$((1*128)) oflag=direct
zfs snapshot tpool/test_fs<strong i="13">@s1</strong>

truncate -s $((2*128*4*1024)) /tpool/test_fs/large_file
dd if=/dev/urandom of=/tpool/test_fs/large_file bs=4k count=128 seek=$((3*128)) conv=notrunc
dd if=/dev/urandom of=/tpool/test_fs/large_file bs=4k count=10 seek=$((2*128)) conv=notrunc
zfs snapshot tpool/test_fs<strong i="14">@s2</strong>

zfs send tpool/test_fs<strong i="15">@s1</strong> | zfs recv tpool/test_fs_copy
zfs send -i tpool/test_fs<strong i="16">@s1</strong> tpool/test_fs<strong i="17">@s2</strong> | zfs recv tpool/test_fs_copy

md5sum /tpool/test_fs/large_file
md5sum /tpool/test_fs_copy/large_file

das wäre sehr hilfreich.

@loyou
lief Ihr Skript auf meinem Centos 6.7 VM für 7 Stunden, durchlief 1110 Iterationen oder so, keine Fehler.
Ich hatte den zfs/spl-Master
[ root@centos-6 zfs-github]# cat /sys/module/{zfs,spl}/version
0.6.5-330_g590c9a0
0.6.5-64_gd2f97b2
nur ein Commit über Ihrem in jedem Repo (scheinbar ohne Bezug).

@bprotopopov
Ich habe Ihr Skript ausgeführt und es kann das 6513-Problem nicht reproduzieren.

Ich bin Ihrem Vorschlag gefolgt und habe die Offset-Größe im Skript protokolliert und dann mit dem nicht zufälligen Skript getestet. Es ist kein 100%iges Problem und manchmal passt es.

Während des Tests habe ich festgestellt, dass mit dem Standardbuild "./autogen.sh && ./configure && make && make install", der nicht /etc/zfs/zpool.cache , in diesem Fall eine Fehlanpassung mit hoher Rate reproduziert werden kann. Wenn jedoch /etc/zfs/zpool.cache erstellt wird, ist es schwer zu reproduzieren (kann es aber immer noch). Ich bin mir nicht sicher, ob es Sinn macht.

Da zpool.cache fehlt, kann zdb -ddddd nicht gestartet werden.
Ich hatte einen VM-Server erstellt und das aktuelle Problem gehalten. Ich werde eine individuelle E-Mail mit dem ip&user&password zur Online-Überprüfung senden.

Außerdem werde ich es auch weiterhin überprüfen. Danke!

@loyou ,

Wenn Sie den Pool importieren, sollten Sie zdb trotzdem ausführen können, glaube ich.

OK, Sie können mich offline unter [email protected] bezüglich der Test-VM skripten ". Ich werde versuchen, am Wochenende dazu zu kommen, kann aber nicht garantieren.

@bprotopopov , danke.
Dies ist einer der Reproduktionsfälle:

zfs create -o recordsize=4k p1/hb
truncate -s 1G /p1/hb/large_file
dd if=/dev/urandom of=/p1/hb/large_file bs=4k count=11264 seek=1152
zfs snapshot p1/hb<strong i="8">@2_1</strong>
truncate -s 4194304 /p1/hb/large_file
dd if=/dev/urandom of=/p1/hb/large_file bs=4k count=152 seek=384 conv=notrunc
dd if=/dev/urandom of=/p1/hb/large_file bs=4k count=10 seek=1408 conv=notrunc
zfs snapshot p1/hb<strong i="9">@2_2</strong>
zfs send p1/hb<strong i="10">@2_1</strong> | zfs recv p1/backup
zfs send -i p1/hb<strong i="11">@2_1</strong> p1/hb<strong i="12">@2_2</strong> | zfs recv p1/backup

MD5 mismatch, hole birth found, exit
d0226974fcab038c843250210b96d401 /p1/hb/large_file
f808cdf1979f0eabf19835ea3e09e8e3 /p1/backup/large_file

Außerdem habe ich den bp-Dump von p1/hb&p1/backup angehängt
p1_hb.zdb.ddddd.txt
p1_backup.zdb.ddddd.txt

Hallo @loyou ,

habe gerade dein Skript ausgeführt. Auf meinem System funktioniert es einwandfrei. Das Problem, das Sie auf Ihrem System sehen, basierend auf den angehängten zdb-Ausgabedateien, scheint ein 6513-Problem zu sein:

Die beiden L1-Bereiche bei den Offsets 480000 und 500000 sollen Löcher mit einer Geburtsepoche ungleich null in Ihren Quell- und Zieldateisystemen sein, aber sie sind mit Daten in Ihrem Backup gefüllt, und es sieht so aus, als würden sie in der Epoche 0 als Löcher in der Geburtsepoche angesehen Ihr Quelldateisystem.

Sie können verwenden

zdb -R p1 0:237e9c00:200:di

um den L2-Metadatenblock Ihres Quell-Datasets auszugeben, und Sie werden mit Sicherheit sehen, was die Blockzeiger sind.

Für das richtige L2 auf meinem System sieht es so aus:

LOCH [L0 nicht zugeordnet] Größe=200L Geburt=0L

LOCH [L0 nicht zugeordnet] Größe=200L Geburt=0L

LOCH [L0 nicht zugeordnet] Größe=200L Geburt=0L

DVA[0]=<3:2f9ada00:1600> DVA[1]=<0:f1f3e00:1600> [L1 ZFS Plain File] Fletcher4 Lz4 LE zusammenhängend eindeutig doppelte Größe=4000L/1600P Geburt=111432L/111432P Fill=128 cksum =1e14

b0d63f2:54c26d5ac1e69:9ba0888976a4e85:59c1e2dcbc65f21a

DVA[0]=<2:e13e200:600> DVA[1]=<3:2fc86200:600> [L1 ZFS Plain File] Fletcher4 Lz4 LE zusammenhängend eindeutig doppelte Größe=4000L/600P Geburt=1111432L/111432P Fill=24 cksum =69551c75

7e:5c6ed46d7d58:2e7671432ae939:11145422d7e7f630

LOCH [L0 nicht zugeordnet] Größe=200L Geburt=0L

LOCH [L0 nicht zugeordnet] Größe=200L Geburt=0L

LOCH [L0 nicht zugeordnet] Größe=200L Geburt=0L

LOCH [L0 nicht zugeordnet] Größe=200L Geburt=0L

LOCH [L1 ZFS Plain File] Größe=4000L Geburt=111432L

LOCH [L1 ZFS Plain File] Größe=4000L Geburt=111432L

DVA[0]=<0:f1d3a00:400> DVA[1]=<1:7f7e600:400> [L1 ZFS Plain File] Fletcher4 Lz4 LE zusammenhängend eindeutig doppelte Größe=4000L/400P Geburt=1111432L/111432P Fill=10 cksum =34e9e2163

2:22aef29e5e10:c2175404e0c4b:2ff61fbf03444b6

...

mit den angezeigten Bereichen 480000 und 500000

...

LOCH [L1 ZFS Plain File] Größe=4000L Geburt=111432L

LOCH [L1 ZFS Plain File] Größe=4000L Geburt=111432L

...

zeigt Löcher mit Geburtsepochen ungleich Null (jede Linie gilt für den L1-Bereich der Größe 80000 Hex).

Von: Neil [email protected]
Gesendet: Montag, 25. Juli 2016 12:22:10
An: zfsonlinux/zfs
Cc: Boris Protopopov; Erwähnen
Betreff: Re: [zfsonlinux/zfs] Unbemerkt beschädigte Datei in Snapshots nach dem Senden/Empfangen (#4809)

@bprotop opovhttps://github.com/bprotopopov , danke.
Dies ist einer der Reproduktionsfälle:

zfs create -o recordsize=4k p1/hb
kürzen -s 1G /p1/hb/large_file
dd if=/dev/urandom of=/p1/hb/large_file bs=4k count=11264 seek=1152
zfs-Schnappschuss p1/ hb@2_1
abschneiden -s 4194304 /p1/hb/large_file
dd if=/dev/urandom of=/p1/hb/large_file bs=4k count=152 seek=384 conv=notrunc
dd if=/dev/urandom of=/p1/hb/large_file bs=4k count=10 seek=1408 conv=notrunc
zfs-Schnappschuss p1/ hb@2_2
zfs senden p1/ hb@2_1 | zfs recv p1/backup
zfs send -i p1/ hb@2_1 p1/ hb@2_2 | zfs recv p1/backup

MD5-Mismatch, Lochgeburt gefunden, Exit
d0226974fcab038c843250210b96d401 /p1/hb/large_file
f808cdf1979f0eabf19835ea3e09e8e3 /p1/backup/large_file

Außerdem habe ich den bp-Dump von p1/hb&p1/backup angehängt
p1_hb.zdb.ddddd. txthttps://github.com/zfsonlinux/zfs/files/380763/p1_hb.zdb.ddddd.txt
p1_backup.zdb.ddddd. txthttps://github.com/zfsonlinux/zfs/files/380765/p1_backup.zdb.ddddd.txt

Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf Gi tHub anhttps://github.com/zfsonlinux/zfs/issues/4809#issuecomment -234833274, oder schalten Sie das MKohYn9EPyMiQnQJks5qZDnygaJpZM4I-nnL.

@bprotopopov
Wir können sehen, dass die Metadaten von p1/{hb,backup}/large_file und p1/backup/large_file 2 weitere indirekte L1-Blöcke erhalten als p1/hb/large_file, was der beschädigte Bereich ist, den wir erhalten.

L2-Metadaten von p1/hb/large_file, zdb -R p1 0:237e9c00:200:di
p1_hb_L2_0:237e9c00:200:di.txt

HOLE [L0 unallocated] size=200L birth=0L
HOLE [L0 unallocated] size=200L birth=0L
HOLE [L0 unallocated] size=200L birth=0L
DVA[0]=<0:237c5c00:1600> DVA[1]=<0:4e0c6fc00:1600> [L1 ZFS plain file] fletcher4 lz4 LE contiguous unique double size=4000L/1600P birth=111640L/111640P fill=128 cksum=1f43e582eff:5d758297d1932:ac7dbe127589265:cc40479b7a6c1a02
DVA[0]=<0:237df200:600> DVA[1]=<0:4e0c71200:600> [L1 ZFS plain file] fletcher4 lz4 LE contiguous unique double size=4000L/600P birth=111640L/111640P fill=24 cksum=65f68de822:617218e5a156:33dad79632620d:13e30014e5ff9c77
HOLE [L0 unallocated] size=200L birth=0L
HOLE [L0 unallocated] size=200L birth=0L
HOLE [L0 unallocated] size=200L birth=0L
HOLE [L0 unallocated] size=200L birth=0L
HOLE [L0 unallocated] size=200L birth=0L
HOLE [L0 unallocated] size=200L birth=0L
DVA[0]=<0:237e9800:400> DVA[1]=<0:4e0c71800:400> [L1 ZFS plain file] fletcher4 lz4 LE contiguous unique double size=4000L/400P birth=111640L/111640P fill=10 cksum=3c70471c1a:2ab5b049d594:fc66313f88a2b:40d11c9085f6614
HOLE [L0 unallocated] size=200L birth=0L
HOLE [L0 unallocated] size=200L birth=0L
HOLE [L0 unallocated] size=200L birth=0L
...

und L2-Metadaten von p1/backup/large_file, zdb -R p1 0:2655ec00:200:di
p1_backup_L2_0:2655ec00:200:di.txt

HOLE [L0 unallocated] size=200L birth=0L
HOLE [L0 unallocated] size=200L birth=0L
HOLE [L0 unallocated] size=200L birth=0L
DVA[0]=<0:26545000:1600> DVA[1]=<0:4e0d28000:1600> [L1 ZFS plain file] fletcher4 lz4 LE contiguous unique double size=4000L/1600P birth=111651L/111651P fill=128 cksum=1ea63edcd43:5a811c96f8444:a6539e50ad7e670:4bb8a78beaab38b4
DVA[0]=<0:2655e600:600> DVA[1]=<0:4e0d29600:600> [L1 ZFS plain file] fletcher4 lz4 LE contiguous unique double size=4000L/600P birth=111651L/111651P fill=24 cksum=65446fb211:6076ba7f1844:3324c8e0e621bb:1389c7c570b9cccb
HOLE [L0 unallocated] size=200L birth=0L
HOLE [L0 unallocated] size=200L birth=0L
HOLE [L0 unallocated] size=200L birth=0L
HOLE [L0 unallocated] size=200L birth=0L
DVA[0]=<0:2388e400:1600> DVA[1]=<0:4e0c8f400:1600> [L1 ZFS plain file] fletcher4 lz4 LE contiguous unique double size=4000L/1600P birth=111646L/111646P fill=128 cksum=1db560423dd:59cd5dadfa628:a7c689bdf8d691d:8db5c5a36c3f22e9
DVA[0]=<0:2390fa00:1600> DVA[1]=<0:4e0c90a00:1600> [L1 ZFS plain file] fletcher4 lz4 LE contiguous unique double size=4000L/1600P birth=111646L/111646P fill=128 cksum=1fece6089a8:5dbded8753784:aae5c4b54dd159f:8b6929104e0662ea
DVA[0]=<0:264c4c00:400> DVA[1]=<0:4e0d27c00:400> [L1 ZFS plain file] fletcher4 lz4 LE contiguous unique double size=4000L/400P birth=111651L/111651P fill=10 cksum=3a6257cc44:288124e7f014:ec3d8e9dd5e64:3c21fed6a53e702
HOLE [L1 ZFS plain file] size=4000L birth=111651L
HOLE [L1 ZFS plain file] size=4000L birth=111651L
HOLE [L1 ZFS plain file] size=4000L birth=111651L
HOLE [L1 ZFS plain file] size=4000L birth=111651L
...

Wir haben einen Zpool, der meiner Meinung nach von diesem Problem betroffen ist, und ich versuche, die richtigen Commits zu erarbeiten, um das Problem zu lösen. Ich arbeite am zfs-0.6.5.7-Tag:

Illumos 6844 - dnode_next_offset kann fiktive Löcher erkennen - 463a8cfe2b293934edd2ee79115b20c4598353d6
OpenZFS 6513 - teilweise gefüllte Löcher verlieren Geburtszeit - bc77ba73fec82d37c0b57949ec29edd9aa207677
Überspringen Sie ctldir znode in zfs_rezget, um Snapdir-Probleme zu beheben - cbecb4fb228bbfedec02eb0a172c681b4338d08f
Möchten Sie tunable, um hole_birth zu ignorieren - 31b86019fd1c2a75548d0a3a8cfd0a29023d55b2

root# cat /sys/module/zfs/parameters/ignore_hole_birth
1

Ursprünglich sahen wir dieses Problem, weil der inkrementell empfangene Stream zeigte, dass der Inhalt zwischen der Zvol und der Datei abweicht. Wenn wir jetzt einige Tests durchführen, scheint die Datei beschädigt zu werden, sobald wir den Snapshot im Quellpool erstellen. Das Tool WriteDiffs.py wurde entwickelt, um nur geänderte Blöcke in eine Datei zu schreiben, damit wir Kuhvorteile erhalten.

root# WriteDiffs.py -c -s /dev/zvol/ztank/reference/ xvda2@ref4000 /ztank/reference/config.ext4
Quelle: /dev/zvol/ztank/reference/ xvda2@ref4000; sha256: b1c4d74fe8f18fbdb0f58074d043f9ba818e26a67ec64a835057e763ac099f13
Ziel: /ztank/reference/config.ext4; sha256: b1c4d74fe8f18fbdb0f58074d043f9ba818e26a67ec64a835057e763ac099f13
Startzeit: 1470734255.66
Endzeit: 1470734256.41
Laufzeit: 0,75s
Insgesamt verglichene Blöcke: 31232
Abgestimmte Blöcke: 31232; Unübertroffene Blöcke: 0
Im Vergleich 41720,54 Blöcke/s; 162,97 MByte/s

# This execution of WriteDiffs.py did not make any change to the copy of the file at /ztank/reference/config.ext4

root# sha256sum /dev/zvol/ztank/reference/ xvda2@ref4000 /ztank/reference/config.ext4
b1c4d74fe8f18fbdb0f58074d043f9ba818e26a67ec64a835057e763ac099f13 /dev/zvol/ztank/reference/ xvda2@ref4000
b1c4d74fe8f18fbdb0f58074d043f9ba818e26a67ec64a835057e763ac099f13 /ztank/reference/config.ext4

root# zfs Snapshot -r hapseed/reference/filesystems/ imageslv@james
root# sha256sum /dev/zvol/ztank/reference/ xvda2@ref4000 /ztank/reference/config.ext4 /ztank/reference/.zfs/snapshot/ref4000/config.ext4 /ztank/reference/.zfs/snapshot/james/ config.ext4
b1c4d74fe8f18fbdb0f58074d043f9ba818e26a67ec64a835057e763ac099f13 /dev/zvol/ztank/reference/ xvda2@ref4000
b1c4d74fe8f18fbdb0f58074d043f9ba818e26a67ec64a835057e763ac099f13 /ztank/reference/config.ext4
4b0906ecf1d4b4356acc7b20a05ed4744f38eede72fc1f96fe138932e37b3422 /ztank/reference/.zfs/snapshot/ref4000/config.ext4
4b0906ecf1d4b4356acc7b20a05ed4744f38eede72fc1f96fe138932e37b3422 /ztank/reference/.zfs/snapshot/james/config.ext4

Wenn wir den Snapshot senden/empfangen, werden sowohl der @ref4000- Snapshot als auch die Datei im Dateisystem mit der Snapshot-Prüfsumme beschädigt

root@other-host# sha256sum /dev/zvol/ztank/reference/ xvda2@ref4000 /ztank/reference/config.ext4 /ztank/reference/.zfs/snapshot/ref4000/config.ext4
b1c4d74fe8f18fbdb0f58074d043f9ba818e26a67ec64a835057e763ac099f13 /dev/zvol/ztank/reference/ xvda2@ref4000
4b0906ecf1d4b4356acc7b20a05ed4744f38eede72fc1f96fe138932e37b3422 /ztank/reference/config.ext4
4b0906ecf1d4b4356acc7b20a05ed4744f38eede72fc1f96fe138932e37b3422 /ztank/reference/.zfs/snapshot/ref4000/config.ext4

@JKDingwall Faszinierend.

Sofern ich mich nicht falsch erinnere, wie das funktioniert, sollten Sie diesen Fehler nicht sehen können, ohne differentielles send-recv zu verwenden oder die ZDB-Ausgabe zu parsen, denn das einzige, was sich in ZFS um die falschen Daten kümmert, ist die Berechnung, ob Löcher gesendet werden sollen für differentielles Senden (und jede Datenbeschädigung "passiert" nur auf dem Empfänger des Snapshots, weil er keine Lücken gesendet hat).

Wenn Sie also sehen, dass Korruption stattfindet, bevor Sie send|recv ausführen, _glaube_ ich nicht, dass dies der fragliche Fehler ist?

Ich denke, es hängt davon ab, was WriteDiffs.py macht.

Dieser Zpool befindet sich auf einem Master-System für unser CI-System, das jede Nacht einen inkrementellen Patch-Stream für diesen Build gegen unsere vorherige Version erzeugt. Wir haben letzte Woche Probleme im inkrementellen Stream beim Empfangen festgestellt und aufgrund der Art und Weise, wie wir das config.ext4-Image aktualisiert haben, angenommen, dass es mit diesem Fehler zusammenhängt. Erst heute habe ich mir die Prüfsummen auf dem Master-Zpool angeschaut und festgestellt, dass die Datei im Snapshot vor dem Senden beschädigt ist. Was wären die interessanten Tests oder Details zum System, um zu bestätigen, ob es sich um ein anderes Problem handelt?

@JKDingwall Das

Verweis auf https://github.com/openzfs/openzfs/pull/173 7176 Noch ein Lochgeburtsproblem [OpenZFS]

https://github.com/zfsonlinux/zfs/pull/4950 OpenZFS 7176 Noch ein Lochgeburtsproblem [PR4950]

@kernelOfTruth , ich habe den Build-Fehler Ihres Pull-Requests

@pcd1193182 Ich habe einen Kern mit dem WriteDiffs.py-Code erstellt: https://gist.github.com/JKDingwall/7f7200a99f52fd3c61b734fbde31edee/49b86a26cb3b9cfd1819d7958e7c8808f6fd991e

Auf unserem System ist nach einem Neustart die Prüfsumme der Datei im Dateisystem ebenfalls beschädigt, um dem Snapshot zu entsprechen. Ich glaube jedoch, dass im Code ein Fehler vorhanden war, bei dem die mmap für die Ausgabedatei nicht geleert wurde, bevor sie geschlossen wurde. Der HEAD des Kerns enthält die neueste Version, die dies tut, und bisher haben wir das Problem nicht wieder gesehen. Es wäre hilfreich zu wissen, ob Sie denken, dass dies die Ursache sein könnte. Wenn ja, hatten wir das Glück, noch nie zuvor erwischt worden zu sein.

@JKDingwall, damit Sie das Problem nicht mehr reproduzieren können

@clopez - Ich kann das Problem immer noch reproduzieren. Patches wie oben angegeben, ignore_hole_birth=1.

Gestern Abend habe ich:
zvol sha256sum: db71ec877acc4f2abc6a9e01781df46e3d1e1416cc2561ccea51d25f348b65ba
Datei nach WriteDiffs.py: db71ec877acc4f2abc6a9e01781df46e3d1e1416cc2561ccea51d25f348b65ba
Snapshot der Datei nach WriteDiffs.py: ebc8d6bd78578640839b0cc4f78695bd40eebce2582d28eb32979a712fe19047

Ich denke, wenn ich neu starte, wird die Datei mit der Snapshot-Prüfsumme beschädigt ...
zvol: db71ec877acc4f2abc6a9e01781df46e3d1e1416cc2561ccea51d25f348b65ba
Datei: ebc8d6bd78578640839b0cc4f78695bd40eebce2582d28eb32979a712fe19047
Datei-Snapshot: ebc8d6bd78578640839b0cc4f78695bd40eebce2582d28eb32979a712fe19047

Könnte es ein Cache-Konsistenzproblem mit Löchern sein?

@JKDingwall
Sie schrieben: "...Erst heute habe ich mir die Prüfsummen auf dem Master-Zpool angeschaut und festgestellt, dass die Datei im Snapshot vor dem Senden beschädigt ist. Was wären die interessanten Tests oder Details zum System, um zu bestätigen, ob dies a anderes Problem?"

Wenn Sie den Pool auf Ihrem Master-System mit zfs send/recv ändern (ich meine, wenn Sie in diesen Master-Pool _empfangen_), dann könnte dies ein Problem mit verpassten Löchern sein. Wenn Sie nicht in den Masterpool _empfangen_ und immer noch eine Beschädigung sehen, ist dies ein anderes Problem.

Es gibt Möglichkeiten, die Metadaten (Blockzeiger) der verdächtigen Dateien mithilfe von zdb zu untersuchen, wie in diesem Thread beschrieben, damit Sie sehen können, ob Lücken übersehen wurden. Voraussetzung für das Auftreten dieser Art von Fehlern ist jedoch, dass der Datensatz mit zfs receive _modified_ ist.

@bprotopopov - es ist kein ZFS-Empfang beteiligt, daher werde ich versuchen, mit einem reproduzierbaren Testfall weitere Informationen zu sammeln und dann eine neue Ausgabe zu eröffnen.

Ich weiß nicht, ob es hierher gehört. Ich habe das Skript verwendet, um von oben zu testen. Und finde das Ergebnis sehr seltsam.

!/bin/sh

ZFSPOOL='DS1'

zfs zerstören $ZFSPOOL/backup -r
zfs zerstören $ZFSPOOL/hb -r
zfs create -o recordsize=4k $ZFSPOOL/hb
truncate -s 1G /$ZFSPOOL/hb/large_file
dd if=/dev/urandom of=/$ZFSPOOL/hb/large_file bs=4k count=11264 seek=1152
zfs-Snapshot $ZFSPOOL/ hb@2_1
truncate -s 4194304 /$ZFSPOOL/hb/large_file
dd if=/dev/urandom of=/$ZFSPOOL/hb/large_file bs=4k count=152 seek=384 conv=notrunc

sleep 5 # Wenn sleep >= 5 Sekunden ist die Prüfsumme anders.

Ich weiß nicht warum 5 Sekunden vielleicht auf anderen Systemen mehr sein müssen.

dd if=/dev/urandom of=/$ZFSPOOL/hb/large_file bs=4k count=10 seek=1408 conv=notrunc
zfs-Snapshot $ZFSPOOL/ hb@2_2
zfs senden $ZFSPOOL/ hb@2_1 | zfs recv $ZFSPOOL/backup
zfs send -i $ZFSPOOL/ hb@2_1 $ZFSPOOL/ hb@2_2 | zfs recv $ZFSPOOL/backup
md5sum /$ZFSPOOL/hb/large_file /$ZFSPOOL/backup/large_file

Ich habe es auf zwei verschiedenen Systemen mehr als 50 Mal aufgerufen. Sleep <5 Sekunden alles OK> = 5 Sekunden Fehler.

System 1 Debian 8 ZFS 0.6.5.7-8-jessie
System 2 Ubuntu 16.04 ZFS 0.6.5.6-0ubuntu10

@datiscum Sofern dies nicht zu einem übergreifenden Fehler für alle Hole_birth-Fehler wird, ist dies kein Fall des Fehlers in illumos 6513, sondern anstelle von illumos 7176, das eine offene PR für ZoL von #4981 hat.

Kurz gesagt, ich denke, Ihr Problem ist nicht das Problem, das in diesem Fehler diskutiert wird, sondern ein bekanntes Problem.

Hey @datiscum , während ich Testskripte für alle gefundenen hole_birth-Fehler geschrieben habe, habe ich festgestellt, dass Ihr gemeldeter Fehler tatsächlich keiner der derzeit im Spiel befindlichen ist! Also habe ich #5030 darüber eingereicht. Vielleicht möchten Sie das abonnieren, um zu sehen, wann es behoben ist.

@JKDingwall Angenommen, Ihr Problem wurde in der Zwischenzeit nicht auf magische Weise behoben, könnten Sie ein neues Problem dazu eröffnen, da ich nicht glaube, dass Ihr Fehler derselbe Fehler ist, um den es in diesem Thread geht?

Schließen. Die gesamte Geburtsoptimierung wurde in der Version 0.6.5.8, 3a8e13688b4ee8c1799edb6484943eae5ea90dd2, standardmäßig deaktiviert. An der Lösung der verschiedenen zugrunde liegenden Probleme wird derzeit im Master gearbeitet.

@behlendorf können wir es auch für 0.7.0 und master deaktivieren?

obwohl mir nach der Diskussion gerade aufgefallen ist, dass ich vergessen hatte, diese Einstellung beim Laden des Moduls zu deaktivieren,

Ich habe zfs send in den letzten Wochen nicht verwendet, beabsichtige jedoch, dies in naher Zukunft erneut zu tun.

für zB Gentoo oder andere aktuelle Benutzer, die sich der Details nicht bewusst sind, könnte dies Kopfschmerzen verursachen, wenn noch Probleme im Code schlummern

Vielen Dank

Ja, das ist eine gute Idee. Wir werden dies definitiv in der endgültigen 0.7.0 beim Tagging deaktivieren, wenn die verschiedenen Probleme bis dahin nicht alle erledigt sind. Es ist auch sinnvoll, es in Master zu deaktivieren, da wir damit begonnen haben, Release-Kandidaten für umfassendere Tests bereitzustellen. Geöffnet PR #5099, um die Standardeinstellung zu ändern.

Kann jemand, der diesen Fehler beobachtet, bitte den Patch in #5099 überprüfen, der den Standardwert ändert.