Zfs: Nicht listebare und verschwindende Dateien
System Information
Geben Sie | ein Version/Name
--- | ---
Verteilungsname | Wissenschaftliches Linux
Verteilungsversion | 6.8
Linux-Kernel | 2.6.32-696.23.1.el6.x86_64
Architektur | x86_64
ZFS-Version | 0.7.7
SPL-Version | 0.7.7
Beschreiben Sie das Problem, das Sie beobachten
Datenverlust beim Kopieren eines Verzeichnisses mit einer großen Anzahl von Dateien. Beispielsweise führt cp -r SRC DST mit 10000 Dateien in SRC wahrscheinlich zu einigen Fehlermeldungen „cp: kann reguläre Datei `DST/XXX‘ erstellen: Kein Platz auf Gerät übrig“ und einigen tausend fehlenden Dateien aus der Auflistung des DST-Verzeichnisses. (Natürlich ist das volle Dateisystem nicht das Problem.)
Die fehlenden Dateien fehlen in dem Sinne, dass sie nicht in der Verzeichnisliste erscheinen, aber über ihren Namen aufgerufen werden können (mit Ausnahme der paar Dateien, für die cp den Fehler „Kein Platz mehr auf dem Gerät“ erzeugt hat ). Zum Beispiel:
# ls -l DST | grep FOO | wc -l
0
# ls -l DST/FOO
-rw-r--r-- 1 root root 5 Apr 6 14:59 DST/FOO
Der Inhalt von DST/FOO ist über den Pfad zugänglich (z. B. funktioniert cat DST/FOO ) und ist derselbe wie bei SRC/FOO. Wenn Caches gelöscht werden ( echo 3 > /proc/sys/vm/drop_caches ) oder die Maschine neu gestartet wird, schlägt das direkte Öffnen von FOO über den Pfad fehl.
ls -ld DST meldet N weniger Hardlinks als SRC, wobei N die Anzahl der Dateien ist, für die cp den Fehler „Kein Platz mehr auf dem Gerät“ gemeldet hat.
Namen fehlender Dateien sind meistens vorhersagbar, wenn SRC klein ist.
Scrub findet keine Fehler.
Ich denke, das Problem trat in 0.7.7 auf, aber ich bin mir nicht sicher.
Beschreiben Sie, wie Sie das Problem reproduzieren können
# mkdir SRC
# for i in $(seq 1 10000); do echo $i > SRC/$i ; done
# cp -r SRC DST
cp: cannot create regular file `DST/8442': No space left on device
cp: cannot create regular file `DST/2629': No space left on device
# ls -l
total 3107
drwxr-xr-x 2 root root 10000 Apr 6 15:28 DST
drwxr-xr-x 2 root root 10002 Apr 6 15:27 SRC
# find DST -type f | wc -l
8186
# ls -l DST | grep 8445 | wc -l
0
# ls -l DST/8445
-rw-r--r-- 1 root root 5 Apr 6 15:28 DST/8445
# cat DST/8445
8445
# echo 3 > /proc/sys/vm/drop_caches
# cat DST/8445
cat: DST/8445: No such file or directory
Schließen Sie alle Warnungen/Fehler/Rückverfolgungen aus den Systemprotokollen ein
# zpool status
pool: tank
state: ONLINE
scan: scrub repaired 0B in 87h47m with 0 errors on Sat Mar 31 07:09:27 2018
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
wwn-0x5000c50085ac4c0f ONLINE 0 0 0
wwn-0x5000c50085acda77 ONLINE 0 0 0
wwn-0x5000c500858db3d7 ONLINE 0 0 0
wwn-0x5000c50085ac9887 ONLINE 0 0 0
wwn-0x5000c50085aca6df ONLINE 0 0 0
raidz1-1 ONLINE 0 0 0
wwn-0x5000c500858db743 ONLINE 0 0 0
wwn-0x5000c500858db347 ONLINE 0 0 0
wwn-0x5000c500858db4a7 ONLINE 0 0 0
wwn-0x5000c500858dbb0f ONLINE 0 0 0
wwn-0x5000c50085acaa97 ONLINE 0 0 0
raidz1-2 ONLINE 0 0 0
wwn-0x5000c50085accb4b ONLINE 0 0 0
wwn-0x5000c50085acab9f ONLINE 0 0 0
wwn-0x5000c50085ace783 ONLINE 0 0 0
wwn-0x5000c500858db67b ONLINE 0 0 0
wwn-0x5000c50085acb983 ONLINE 0 0 0
raidz1-3 ONLINE 0 0 0
wwn-0x5000c50085ac4fd7 ONLINE 0 0 0
wwn-0x5000c50085acb24b ONLINE 0 0 0
wwn-0x5000c50085ace13b ONLINE 0 0 0
wwn-0x5000c500858db43f ONLINE 0 0 0
wwn-0x5000c500858db61b ONLINE 0 0 0
raidz1-4 ONLINE 0 0 0
wwn-0x5000c500858dbbb7 ONLINE 0 0 0
wwn-0x5000c50085acce7f ONLINE 0 0 0
wwn-0x5000c50085acd693 ONLINE 0 0 0
wwn-0x5000c50085ac3d87 ONLINE 0 0 0
wwn-0x5000c50085acc89b ONLINE 0 0 0
raidz1-5 ONLINE 0 0 0
wwn-0x5000c500858db28b ONLINE 0 0 0
wwn-0x5000c500858db68f ONLINE 0 0 0
wwn-0x5000c500858dbadf ONLINE 0 0 0
wwn-0x5000c500858db623 ONLINE 0 0 0
wwn-0x5000c500858db48b ONLINE 0 0 0
raidz1-6 ONLINE 0 0 0
wwn-0x5000c500858db6ef ONLINE 0 0 0
wwn-0x5000c500858db39b ONLINE 0 0 0
wwn-0x5000c500858db47f ONLINE 0 0 0
wwn-0x5000c500858dbb23 ONLINE 0 0 0
wwn-0x5000c500858db803 ONLINE 0 0 0
logs
zfs-slog ONLINE 0 0 0
spares
wwn-0x5000c500858db463 AVAIL
errors: No known data errors
# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 254T 159T 94.3T - 27% 62% 1.00x ONLINE -
md5-f618a12917d64a78c208de73972d8f89
# zfs list -t all
NAME USED AVAIL REFER MOUNTPOINT
tank 127T 69.0T 11.5T /mnt/tank
tank/jade 661G 69.0T 661G /mnt/tank/jade
tank/simprod 115T 14.8T 115T /mnt/tank/simprod
md5-f618a12917d64a78c208de73972d8f89
# zfs get all tank
NAME PROPERTY VALUE SOURCE
tank type filesystem -
tank creation Sat Jan 20 12:11 2018 -
tank used 127T -
tank available 68.9T -
tank referenced 11.6T -
tank compressratio 1.00x -
tank mounted yes -
tank quota none default
tank reservation none default
tank recordsize 128K default
tank mountpoint /mnt/tank local
tank sharenfs off default
tank checksum on default
tank compression off default
tank atime off local
tank devices on default
tank exec on default
tank setuid on default
tank readonly off default
tank zoned off default
tank snapdir hidden default
tank aclinherit restricted default
tank createtxg 1 -
tank canmount on default
tank xattr sa local
tank copies 1 default
tank version 5 -
tank utf8only off -
tank normalization none -
tank casesensitivity sensitive -
tank vscan off default
tank nbmand off default
tank sharesmb off default
tank refquota none default
tank refreservation none default
tank guid 2271746520743372128 -
tank primarycache all default
tank secondarycache all default
tank usedbysnapshots 0B -
tank usedbydataset 11.6T -
tank usedbychildren 116T -
tank usedbyrefreservation 0B -
tank logbias latency default
tank dedup off default
tank mlslabel none default
tank sync standard default
tank dnodesize legacy default
tank refcompressratio 1.00x -
tank written 11.6T -
tank logicalused 128T -
tank logicalreferenced 11.6T -
tank volmode default default
tank filesystem_limit none default
tank snapshot_limit none default
tank filesystem_count none default
tank snapshot_count none default
tank snapdev hidden default
tank acltype off default
tank context none default
tank fscontext none default
tank defcontext none default
tank rootcontext none default
tank relatime off default
tank redundant_metadata all default
tank overlay off default
md5-f618a12917d64a78c208de73972d8f89
# zpool get all tank
NAME PROPERTY VALUE SOURCE
tank size 254T -
tank capacity 62% -
tank altroot - default
tank health ONLINE -
tank guid 7056741522691970971 -
tank version - default
tank bootfs - default
tank delegation on default
tank autoreplace on local
tank cachefile - default
tank failmode wait default
tank listsnapshots off default
tank autoexpand off default
tank dedupditto 0 default
tank dedupratio 1.00x -
tank free 94.2T -
tank allocated 160T -
tank readonly off -
tank ashift 0 default
tank comment - default
tank expandsize - -
tank freeing 0 -
tank fragmentation 27% -
tank leaked 0 -
tank multihost off default
tank feature<strong i="5">@async_destroy</strong> enabled local
tank feature<strong i="6">@empty_bpobj</strong> active local
tank feature<strong i="7">@lz4_compress</strong> active local
tank feature<strong i="8">@multi_vdev_crash_dump</strong> enabled local
tank feature<strong i="9">@spacemap_histogram</strong> active local
tank feature<strong i="10">@enabled_txg</strong> active local
tank feature<strong i="11">@hole_birth</strong> active local
tank feature<strong i="12">@extensible_dataset</strong> active local
tank feature<strong i="13">@embedded_data</strong> active local
tank feature<strong i="14">@bookmarks</strong> enabled local
tank feature<strong i="15">@filesystem_limits</strong> enabled local
tank feature<strong i="16">@large_blocks</strong> enabled local
tank feature<strong i="17">@large_dnode</strong> enabled local
tank feature<strong i="18">@sha512</strong> enabled local
tank feature<strong i="19">@skein</strong> enabled local
tank feature<strong i="20">@edonr</strong> enabled local
tank feature<strong i="21">@userobj_accounting</strong> active local
vbrik
Alle 108 Kommentare
Ich kann das gleiche Verhalten bei einer minimalen CentOS 7.4-Installation (die in VirtualBox ausgeführt wird) und dem neuesten ZFS 0.7.7 bestätigen . Bitte beachten Sie, dass beim Kopieren etwas größerer Dateien (z. B. Kernel-Quelle) dies nicht passiert, es scheint also so etwas wie eine Race-Bedingung zu sein ...
; the only changed property was xattr=sa
[root<strong i="7">@localhost</strong> ~]# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 7.94G 25.3M 7.91G - 0% 0% 1.00x ONLINE -
[root<strong i="8">@localhost</strong> ~]# zfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 24.5M 7.67G 3.36M /tank
tank/test 21.0M 7.67G 21.0M /tank/test
; creating the source dir on a XFS filesystem
[root<strong i="9">@localhost</strong> ~]# cd /root/
[root<strong i="10">@localhost</strong> ~]# mkdir test
[root<strong i="11">@localhost</strong> ~]# cd test
[root<strong i="12">@localhost</strong> ~]# for i in $(seq 1 10000); do echo $i > SRC/$i ; done
; copying from XFS to ZFS: no problem at all
[root<strong i="13">@localhost</strong> ~]# cd /tank/test
[root<strong i="14">@localhost</strong> test]# cp -r /root/test/SRC/ DST1
[root<strong i="15">@localhost</strong> test]# cp -r /root/test/SRC/ DST2
[root<strong i="16">@localhost</strong> test]# cp -r /root/test/SRC/ DST3
[root<strong i="17">@localhost</strong> test]# find DST1/ | wc -l
10001
[root<strong i="18">@localhost</strong> test]# find DST2/ | wc -l
10001
[root<strong i="19">@localhost</strong> test]# find DST3/ | wc -l
10001
; copying from ZFS dataset itself: big troubles!
[root<strong i="20">@localhost</strong> test]# rm -rf SRC DST1 DST2 DST3
[root<strong i="21">@localhost</strong> test]# cp -r /root/test/SRC .
[root<strong i="22">@localhost</strong> test]# cp -r SRC DST1
cp: cannot create regular file ‘DST1/8809’: No space left on device
[root<strong i="23">@localhost</strong> test]# cp -r SRC DST2
[root<strong i="24">@localhost</strong> test]# cp -r SRC DST3
cp: cannot create regular file ‘DST3/6507’: No space left on device
[root<strong i="25">@localhost</strong> test]# find DST1/ | wc -l
10000
[root<strong i="26">@localhost</strong> test]# find DST2/ | wc -l
10001
[root<strong i="27">@localhost</strong> test]# find DST3/ | wc -l
8189
; disabling cache: nothing changes (we continue to "lose" files)
[root<strong i="28">@localhost</strong> test]# zfs set primarycache=none tank
[root<strong i="29">@localhost</strong> test]# zfs set primarycache=none tank/test
[root<strong i="30">@localhost</strong> test]# echo 3 > /proc/sys/vm/drop_caches
[root<strong i="31">@localhost</strong> test]# rm -rf SRC; mkdir SRC; for i in $(seq 1 10000); do echo $i > SRC/$i ; done; find SRC | wc -l
10001
[root<strong i="32">@localhost</strong> test]# rm -rf SRC; mkdir SRC; for i in $(seq 1 10000); do echo $i > SRC/$i ; done; find SRC | wc -l
10001
[root<strong i="33">@localhost</strong> test]# rm -rf SRC; mkdir SRC; for i in $(seq 1 10000); do echo $i > SRC/$i ; done; find SRC | wc -l
10001
Das Problem tritt NICHT in ZoL 0.7.6 auf:
; creating the dataset and copying the SRC dir
[root<strong i="7">@localhost</strong> ~]# zfs create tank/test
[root<strong i="8">@localhost</strong> ~]# zfs set xattr=sa tank
[root<strong i="9">@localhost</strong> ~]# zfs set xattr=sa tank/test
[root<strong i="10">@localhost</strong> ~]# cp -r /root/test/SRC/ /tank/test/
[root<strong i="11">@localhost</strong> ~]# cd /tank/test/
[root<strong i="12">@localhost</strong> test]# find SRC/ | wc -l
10001
; more copies
[root<strong i="13">@localhost</strong> test]# cp -r SRC/ DST
[root<strong i="14">@localhost</strong> test]# cp -r SRC/ DST1
[root<strong i="15">@localhost</strong> test]# cp -r SRC/ DST2
[root<strong i="16">@localhost</strong> test]# cp -r SRC/ DST3
[root<strong i="17">@localhost</strong> test]# cp -r SRC/ DST4
[root<strong i="18">@localhost</strong> test]# cp -r SRC/ DST5
[root<strong i="19">@localhost</strong> test]# find DST | wc -l
10001
[root<strong i="20">@localhost</strong> test]# find DST1 | wc -l
10001
[root<strong i="21">@localhost</strong> test]# find DST2 | wc -l
10001
[root<strong i="22">@localhost</strong> test]# find DST3 | wc -l
10001
[root<strong i="23">@localhost</strong> test]# find DST4 | wc -l
10001
[root<strong i="24">@localhost</strong> test]# find DST5 | wc -l
10001
Vielleicht kann es helfen. Hier finden Sie die Ausgabe von zdb -dddddddd tank/test 192784 (ein "gutes" DST-Verzeichnis):
Dataset tank/test [ZPL], ID 74, cr_txg 13, 26.5M, 190021 objects, rootbp DVA[0]=<0:5289e00:200> DVA[1]=<0:65289e00:200> [L0 DMU objset] fletcher4 lz4 LE contiguous unique double size=800L/200P birth=123L/123P fill=190021 cksum=d622b78d2:50c053a50d0:fca8cd4455d7:2216d160ee7f7d
Object lvl iblk dblk dsize dnsize lsize %full type
192784 2 128K 16K 909K 512 1.02M 100.00 ZFS directory (K=inherit) (Z=inherit)
272 bonus System attributes
dnode flags: USED_BYTES USERUSED_ACCOUNTED USEROBJUSED_ACCOUNTED
dnode maxblkid: 64
path /DST16
uid 0
gid 0
atime Sat Apr 7 01:11:29 2018
mtime Sat Apr 7 01:11:31 2018
ctime Sat Apr 7 01:11:31 2018
crtime Sat Apr 7 01:11:29 2018
gen 97
mode 40755
size 10002
parent 34
links 2
pflags 40800000144
SA xattrs: 96 bytes, 1 entries
security.selinux = unconfined_u:object_r:unlabeled_t:s0\000
Fat ZAP stats:
Pointer table:
1024 elements
zt_blk: 0
zt_numblks: 0
zt_shift: 10
zt_blks_copied: 0
zt_nextblk: 0
ZAP entries: 10000
Leaf blocks: 64
Total blocks: 65
zap_block_type: 0x8000000000000001
zap_magic: 0x2f52ab2ab
zap_salt: 0x13c18a19
Leafs with 2^n pointers:
4: 64 ****************************************
Blocks with n*5 entries:
9: 64 ****************************************
Blocks n/10 full:
6: 4 ****
7: 43 ****************************************
8: 16 ***************
9: 1 *
Entries with n chunks:
3: 10000 ****************************************
Buckets with n entries:
0: 24119 ****************************************
1: 7414 *************
2: 1126 **
3: 102 *
4: 7 *
... und zdb -dddddddd tank/test 202785 (ein "schlechtes" DST-Verzeichnis):
Dataset tank/test [ZPL], ID 74, cr_txg 13, 26.5M, 190021 objects, rootbp DVA[0]=<0:5289e00:200> DVA[1]=<0:65289e00:200> [L0 DMU objset] fletcher4 lz4 LE contiguous unique double size=800L/200P birth=123L/123P fill=190021 cksum=d622b78d2:50c053a50d0:fca8cd4455d7:2216d160ee7f7d
Object lvl iblk dblk dsize dnsize lsize %full type
202785 2 128K 16K 766K 512 896K 100.00 ZFS directory (K=inherit) (Z=inherit)
272 bonus System attributes
dnode flags: USED_BYTES USERUSED_ACCOUNTED USEROBJUSED_ACCOUNTED
dnode maxblkid: 55
path /DST17
uid 0
gid 0
atime Sat Apr 7 01:12:49 2018
mtime Sat Apr 7 01:11:33 2018
ctime Sat Apr 7 01:11:33 2018
crtime Sat Apr 7 01:11:32 2018
gen 98
mode 40755
size 10001
parent 34
links 2
pflags 40800000144
SA xattrs: 96 bytes, 1 entries
security.selinux = unconfined_u:object_r:unlabeled_t:s0\000
Fat ZAP stats:
Pointer table:
1024 elements
zt_blk: 0
zt_numblks: 0
zt_shift: 10
zt_blks_copied: 0
zt_nextblk: 0
ZAP entries: 8259
Leaf blocks: 55
Total blocks: 56
zap_block_type: 0x8000000000000001
zap_magic: 0x2f52ab2ab
zap_salt: 0x1bf8e8a3
Leafs with 2^n pointers:
4: 50 ****************************************
5: 3 ***
6: 2 **
Blocks with n*5 entries:
9: 55 ****************************************
Blocks n/10 full:
5: 6 ******
6: 7 *******
7: 32 ********************************
8: 6 ******
9: 4 ****
Entries with n chunks:
3: 8259 ****************************************
Buckets with n entries:
0: 20964 ****************************************
1: 6217 ************
2: 904 **
3: 66 *
4: 9 *
shodanshok
am 7. Apr. 2018
Wir sehen auch ein ähnliches Verhalten seit der Installation von 0.7.7
alatteri
am 7. Apr. 2018
Ich habe ein handgebautes ZoL 0.7.7 auf einem Standard-Ubuntu 16.04-Server (derzeit mit Ubuntu-Kernel-Version '4.4.0-109-generic') und ich kann dieses Problem darauf nicht reproduzieren, nach der Reproduktion hier und einigen Varianten (z. B. mit 'seq -w', um alle Dateinamen gleich groß zu machen). Der Pool, gegen den ich teste, hat einen einzigen gespiegelten vdev.
siebenmann
am 7. Apr. 2018
Ein weiterer Datenpunkt, in der Hoffnung, dass er hilft, das Problem einzugrenzen.
Ich kann das Problem auf den wenigen Maschinen, die ich hier habe, nicht reproduzieren, weder mit 10k-Dateien noch mit 100k oder sogar 1M. Sie alle haben eine sehr ähnliche Konfiguration. Sie verwenden ein einzelnes gespiegeltes vdev mit 2 Laufwerken. Die Laufwerke sind Samsung SSD 950 PRO 512 GB (NVMe, ziemlich schnell).
$ uname -a
Linux pat 4.9.90-gentoo #1 SMP PREEMPT Tue Mar 27 00:19:59 CEST 2018 x86_64 Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz GenuineIntel GNU/Linux
$ qlist -I -v zfs-kmod
sys-fs/zfs-kmod-0.7.7
$ qlist -I -v spl
sys-kernel/spl-0.7.7
$ zpool status
pool: pat:pool
state: ONLINE
scan: scrub repaired 0B in 0h1m with 0 errors on Sat Apr 7 03:35:12 2018
config:
NAME STATE READ WRITE CKSUM
pat:pool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
nvme0n1p4 ONLINE 0 0 0
nvme1n1p4 ONLINE 0 0 0
spares
ata-Samsung_SSD_850_EVO_1TB_S2RFNXAH118721D-part8 AVAIL
errors: No known data errors
$ zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
pat:pool 408G 110G 298G - 18% 26% 1.00x ONLINE -
$ zpool get all pat:pool
NAME PROPERTY VALUE SOURCE
pat:pool size 408G -
pat:pool capacity 26% -
pat:pool altroot - default
pat:pool health ONLINE -
pat:pool guid 16472389984482033769 -
pat:pool version - default
pat:pool bootfs - default
pat:pool delegation on default
pat:pool autoreplace on local
pat:pool cachefile - default
pat:pool failmode wait default
pat:pool listsnapshots off default
pat:pool autoexpand off default
pat:pool dedupditto 0 default
pat:pool dedupratio 1.00x -
pat:pool free 298G -
pat:pool allocated 110G -
pat:pool readonly off -
pat:pool ashift 12 local
pat:pool comment - default
pat:pool expandsize - -
pat:pool freeing 0 -
pat:pool fragmentation 18% -
pat:pool leaked 0 -
pat:pool multihost off default
pat:pool feature<strong i="7">@async_destroy</strong> enabled local
pat:pool feature<strong i="8">@empty_bpobj</strong> active local
pat:pool feature<strong i="9">@lz4_compress</strong> active local
pat:pool feature<strong i="10">@multi_vdev_crash_dump</strong> enabled local
pat:pool feature<strong i="11">@spacemap_histogram</strong> active local
pat:pool feature<strong i="12">@enabled_txg</strong> active local
pat:pool feature<strong i="13">@hole_birth</strong> active local
pat:pool feature<strong i="14">@extensible_dataset</strong> active local
pat:pool feature<strong i="15">@embedded_data</strong> active local
pat:pool feature<strong i="16">@bookmarks</strong> enabled local
pat:pool feature<strong i="17">@filesystem_limits</strong> enabled local
pat:pool feature<strong i="18">@large_blocks</strong> enabled local
pat:pool feature<strong i="19">@large_dnode</strong> enabled local
pat:pool feature<strong i="20">@sha512</strong> enabled local
pat:pool feature<strong i="21">@skein</strong> enabled local
pat:pool feature<strong i="22">@edonr</strong> enabled local
pat:pool feature<strong i="23">@userobj_accounting</strong> active local
$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
(...)
pat:pool/home/joe/tmp 27.9G 285G 27.9G /home/joe/tmp
(...)
$ zfs get all pat:pool/home/joe/tmp
NAME PROPERTY VALUE SOURCE
pat:pool/home/joe/tmp type filesystem -
pat:pool/home/joe/tmp creation Sat Mar 12 17:32 2016 -
pat:pool/home/joe/tmp used 27.9G -
pat:pool/home/joe/tmp available 285G -
pat:pool/home/joe/tmp referenced 27.9G -
pat:pool/home/joe/tmp compressratio 1.16x -
pat:pool/home/joe/tmp mounted yes -
pat:pool/home/joe/tmp quota none default
pat:pool/home/joe/tmp reservation none default
pat:pool/home/joe/tmp recordsize 128K default
pat:pool/home/joe/tmp mountpoint /home/joe/tmp inherited from pat:pool/home
pat:pool/home/joe/tmp sharenfs off default
pat:pool/home/joe/tmp checksum on default
pat:pool/home/joe/tmp compression lz4 inherited from pat:pool
pat:pool/home/joe/tmp atime off inherited from pat:pool
pat:pool/home/joe/tmp devices on default
pat:pool/home/joe/tmp exec on default
pat:pool/home/joe/tmp setuid on default
pat:pool/home/joe/tmp readonly off default
pat:pool/home/joe/tmp zoned off default
pat:pool/home/joe/tmp snapdir hidden default
pat:pool/home/joe/tmp aclinherit restricted default
pat:pool/home/joe/tmp createtxg 507 -
pat:pool/home/joe/tmp canmount on default
pat:pool/home/joe/tmp xattr sa inherited from pat:pool
pat:pool/home/joe/tmp copies 1 default
pat:pool/home/joe/tmp version 5 -
pat:pool/home/joe/tmp utf8only off -
pat:pool/home/joe/tmp normalization none -
pat:pool/home/joe/tmp casesensitivity sensitive -
pat:pool/home/joe/tmp vscan off default
pat:pool/home/joe/tmp nbmand off default
pat:pool/home/joe/tmp sharesmb off default
pat:pool/home/joe/tmp refquota none default
pat:pool/home/joe/tmp refreservation none default
pat:pool/home/joe/tmp guid 10274125767907263189 -
pat:pool/home/joe/tmp primarycache all default
pat:pool/home/joe/tmp secondarycache all default
pat:pool/home/joe/tmp usedbysnapshots 0B -
pat:pool/home/joe/tmp usedbydataset 27.9G -
pat:pool/home/joe/tmp usedbychildren 0B -
pat:pool/home/joe/tmp usedbyrefreservation 0B -
pat:pool/home/joe/tmp logbias latency default
pat:pool/home/joe/tmp dedup off default
pat:pool/home/joe/tmp mlslabel none default
pat:pool/home/joe/tmp sync standard default
pat:pool/home/joe/tmp dnodesize legacy default
pat:pool/home/joe/tmp refcompressratio 1.16x -
pat:pool/home/joe/tmp written 27.9G -
pat:pool/home/joe/tmp logicalused 31.6G -
pat:pool/home/joe/tmp logicalreferenced 31.6G -
pat:pool/home/joe/tmp volmode default default
pat:pool/home/joe/tmp filesystem_limit none default
pat:pool/home/joe/tmp snapshot_limit none default
pat:pool/home/joe/tmp filesystem_count none default
pat:pool/home/joe/tmp snapshot_count none default
pat:pool/home/joe/tmp snapdev hidden default
pat:pool/home/joe/tmp acltype posixacl inherited from pat:pool
pat:pool/home/joe/tmp context none default
pat:pool/home/joe/tmp fscontext none default
pat:pool/home/joe/tmp defcontext none default
pat:pool/home/joe/tmp rootcontext none default
pat:pool/home/joe/tmp relatime off default
pat:pool/home/joe/tmp redundant_metadata all default
pat:pool/home/joe/tmp overlay off default
pat:pool/home/joe/tmp net.c-space:snapshots keep=1M inherited from pat:pool/home/joe
pat:pool/home/joe/tmp net.c-space:root 0 inherited from pat:pool
rblank
am 7. Apr. 2018
Ich bekomme eine schlechtere Situation auf dem neuesten Centos 7 mit kmod:
`[root @zirconia test]# mkdir SRC
[root @zirconia test]# für i in $(seq 1 10000); do echo $i > SRC/$i ; fertig
[ root@zirconia test]# cp -r SRC DST
cp: Normale Datei 'DST/5269' kann nicht erstellt werden: Kein Platz mehr auf dem Gerät
cp: Normale Datei 'DST/9923' kann nicht erstellt werden: Kein Platz mehr auf dem Gerät
[ root@zirconia test]# cat DST/5269
cat: DST/5269: Keine solche Datei oder Verzeichnis
[ root@zirconia test]# cat DST/9923
cat: DST/9923: Keine solche Datei oder Verzeichnis
[ root@zirconia test]# cat DST/9924
9924
[ root@zirconia test]# cat DST/9923
cat: DST/9923: Keine solche Datei oder Verzeichnis
[ root@zirconia test]# ls -l DST/9923
ls: kann nicht auf DST/9923 zugreifen: Keine solche Datei oder kein Verzeichnis
[ root@zirconia test]# zpool-status
Schwimmbad: Lagerung
Zustand: ONLINE
Scannen: keine angefordert
Konfiguration:
NAME STATE READ WRITE CKSUM
storage ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30KPM0D ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30NJDDD ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30NJAHD ONLINE 0 0 0
raidz1-1 ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30NGXDD ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30NJ91D ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30LN7GD ONLINE 0 0 0
raidz1-2 ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30NJM5D ONLINE 0 0 0
ata-HGST_HUS724020ALA640_PN2134P5GAY9PX ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30NJD5D ONLINE 0 0 0
raidz1-3 ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30NJD8D ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30NJHVD ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30K5PMD ONLINE 0 0 0
raidz1-4 ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30NLZLD ONLINE 0 0 0
ata-Hitachi_HDS723020BLA642_MN1220F30MVW4D ONLINE 0 0 0
ata-HGST_HUS724020ALA640_PN2134P5GBBL9X ONLINE 0 0 0
logs
mirror-5 ONLINE 0 0 0
nvme0n1p1 ONLINE 0 0 0
nvme1n1p1 ONLINE 0 0 0
cache
nvme0n1p2 ONLINE 0 0 0
nvme1n1p2 ONLINE 0 0 0`
ich
alexcrow1974
am 7. Apr. 2018
@rblank Hast du leere Dateien verwendet? Bitte versuche folgendes:
- cd in Ihren ZFS-Datensatz
mkdir SRC; for i in $(seq 1 10000); do echo -n > SRC/$i; done; find SRC | wc -lausführen- Geben Sie jetzt
for i in $(seq 1 10); do cp -r SRC DST$i; find DST$i | wc -l; done
Danke.
shodanshok
am 7. Apr. 2018
Ich habe die genauen Befehle des OP verwendet (die nicht leere Dateien erstellen) und nur 10000 in 100000 und 1000000 geändert. Aber der Vollständigkeit halber habe ich auch Ihre ausprobiert.
$ mkdir SRC; for i in $(seq 1 10000); do echo -n > SRC/$i; done; find SRC | wc -l
10001
$ for i in $(seq 1 10); do cp -r SRC DST$i; find DST$i | wc -l; done
10001
10001
10001
10001
10001
10001
10001
10001
10001
10001
Die wenigen Datenpunkte oben deuten schwach auf raidz hin, da sich bisher niemand auf Mirrors reproduzieren konnte.
rblank
am 7. Apr. 2018
Bei einem meiner Becken funktioniert das einwandfrei, bei einem anderen zeigt es die Probleme. Beide Datensätze gehören zum selben Pool.
bash-4.2$ mkdir SRC
bash-4.2$ für i in $(seq 1 10000); do echo $i > SRC/$i ; fertig
bash-4.2$ cp -r SRC DST
cp: Normale Datei 'DST/222' kann nicht erstellt werden: Kein Platz mehr auf dem Gerät
cp: Normale Datei 'DST/6950' kann nicht erstellt werden: Kein Platz mehr auf dem Gerät
Auf beast/engineering laufen die obigen Befehle ohne Probleme. Auf beast/dataio scheitern sie.
bash-4.2$ zfs get all beast/engineering
NAME PROPERTY VALUE SOURCE
beast/engineering type filesystem -
beast/engineering creation Sun Nov 5 17:53 2017 -
beast/engineering used 1.85T -
beast/engineering available 12.0T -
beast/engineering referenced 1.85T -
beast/engineering compressratio 1.04x -
beast/engineering mounted yes -
beast/engineering quota none default
beast/engineering reservation none default
beast/engineering recordsize 1M inherited from beast
beast/engineering mountpoint /beast/engineering default
beast/engineering sharenfs on inherited from beast
beast/engineering checksum on default
beast/engineering compression lz4 inherited from beast
beast/engineering atime off inherited from beast
beast/engineering devices on default
beast/engineering exec on default
beast/engineering setuid on default
beast/engineering readonly off default
beast/engineering zoned off default
beast/engineering snapdir hidden default
beast/engineering aclinherit restricted default
beast/engineering createtxg 20615173 -
beast/engineering canmount on default
beast/engineering xattr sa inherited from beast
beast/engineering copies 1 default
beast/engineering version 5 -
beast/engineering utf8only off -
beast/engineering normalization none -
beast/engineering casesensitivity sensitive -
beast/engineering vscan off default
beast/engineering nbmand off default
beast/engineering sharesmb off inherited from beast
beast/engineering refquota none default
beast/engineering refreservation none default
beast/engineering guid 18311947624891459017 -
beast/engineering primarycache metadata local
beast/engineering secondarycache all default
beast/engineering usedbysnapshots 151M -
beast/engineering usedbydataset 1.85T -
beast/engineering usedbychildren 0B -
beast/engineering usedbyrefreservation 0B -
beast/engineering logbias latency default
beast/engineering dedup off default
beast/engineering mlslabel none default
beast/engineering sync disabled inherited from beast
beast/engineering dnodesize auto inherited from beast
beast/engineering refcompressratio 1.04x -
beast/engineering written 0 -
beast/engineering logicalused 1.92T -
beast/engineering logicalreferenced 1.92T -
beast/engineering volmode default default
beast/engineering filesystem_limit none default
beast/engineering snapshot_limit none default
beast/engineering filesystem_count none default
beast/engineering snapshot_count none default
beast/engineering snapdev hidden default
beast/engineering acltype posixacl inherited from beast
beast/engineering context none default
beast/engineering fscontext none default
beast/engineering defcontext none default
beast/engineering rootcontext none default
beast/engineering relatime off default
beast/engineering redundant_metadata all default
beast/engineering overlay off default
beast/engineering com.sun:auto-snapshot true inherited from beast
bash-4.2$ zfs get all beast/dataio
NAME PROPERTY VALUE SOURCE
beast/dataio type filesystem -
beast/dataio creation Fri Oct 13 11:13 2017 -
beast/dataio used 45.0T -
beast/dataio available 12.0T -
beast/dataio referenced 45.0T -
beast/dataio compressratio 1.09x -
beast/dataio mounted yes -
beast/dataio quota none default
beast/dataio reservation none default
beast/dataio recordsize 1M inherited from beast
beast/dataio mountpoint /beast/dataio default
beast/dataio sharenfs on inherited from beast
beast/dataio checksum on default
beast/dataio compression lz4 inherited from beast
beast/dataio atime off inherited from beast
beast/dataio devices on default
beast/dataio exec on default
beast/dataio setuid on default
beast/dataio readonly off default
beast/dataio zoned off default
beast/dataio snapdir hidden default
beast/dataio aclinherit restricted default
beast/dataio createtxg 19156147 -
beast/dataio canmount on default
beast/dataio xattr sa inherited from beast
beast/dataio copies 1 default
beast/dataio version 5 -
beast/dataio utf8only off -
beast/dataio normalization none -
beast/dataio casesensitivity sensitive -
beast/dataio vscan off default
beast/dataio nbmand off default
beast/dataio sharesmb off inherited from beast
beast/dataio refquota none default
beast/dataio refreservation none default
beast/dataio guid 7216940837685529084 -
beast/dataio primarycache all default
beast/dataio secondarycache all default
beast/dataio usedbysnapshots 0B -
beast/dataio usedbydataset 45.0T -
beast/dataio usedbychildren 0B -
beast/dataio usedbyrefreservation 0B -
beast/dataio logbias latency default
beast/dataio dedup off default
beast/dataio mlslabel none default
beast/dataio sync disabled inherited from beast
beast/dataio dnodesize auto inherited from beast
beast/dataio refcompressratio 1.09x -
beast/dataio written 45.0T -
beast/dataio logicalused 49.3T -
beast/dataio logicalreferenced 49.3T -
beast/dataio volmode default default
beast/dataio filesystem_limit none default
beast/dataio snapshot_limit none default
beast/dataio filesystem_count none default
beast/dataio snapshot_count none default
beast/dataio snapdev hidden default
beast/dataio acltype posixacl inherited from beast
beast/dataio context none default
beast/dataio fscontext none default
beast/dataio defcontext none default
beast/dataio rootcontext none default
beast/dataio relatime off default
beast/dataio redundant_metadata all default
beast/dataio overlay off default
beast/dataio com.sun:auto-snapshot false local
Ich denke, das Problem hängt mit primarycache=all zusammen. Wenn ich einen Pool auf primarycache=metadata setze, gibt es keine Fehler.
alatteri
am 7. Apr. 2018
@rblank Ich habe das Problem mit einem einfachen Single-Vdev-Pool repliziert. Ich werde versuchen, mich trotzdem mit dem Spiegel zu melden.
@alatteri Welches Pool-/Vdev-Layout verwenden Sie? Können Sie zpool status auf beiden Maschinen anzeigen? Ich habe es mit primarycache=none versucht und es ist fehlgeschlagen, wenn auch mit viel geringerer Häufigkeit (dh: es ist nach der 5. Kopie fehlgeschlagen). Ich werde es mit primarycache=metadata versuchen.
shodanshok
am 7. Apr. 2018
Gleiche Maschine, unterschiedliche Datensätze im gleichen Pool.
beast: /nfs/beast/home/alan % zpool status
pool: beast
state: ONLINE
scan: scrub canceled on Fri Mar 2 16:47:01 2018
config:
NAME STATE READ WRITE CKSUM
beast ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NAHN5M1X ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NAHN5NPX ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NAHNP9BX ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NAHN6M4Y ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NAHNPBLX ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NAHKY7PX ONLINE 0 0 0
raidz2-1 ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCG1G8SL ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCG1BVVL ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCG13K0L ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCG1GA9L ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCG1G9YL ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCG6D9ZS ONLINE 0 0 0
raidz2-2 ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCG68U3S ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCG2WW7S ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NAHMHVGY ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NAHKRYUX ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NAHKXMKX ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCG5ZYKS ONLINE 0 0 0
raidz2-3 ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCGSM01S ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCGSY9HS ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCGTHJUS ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCGTKV1S ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCGTMN4S ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCGTGTLS ONLINE 0 0 0
raidz2-4 ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCGTKUWS ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCGTG3YS ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCGTLYZS ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCGSZ2GS ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCGSV93S ONLINE 0 0 0
ata-HGST_HDN726060ALE610_NCGT04NS ONLINE 0 0 0
raidz2-5 ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HHZGSB ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1GTE6HD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1GU06VD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1GS5KNF ONLINE 0 0 0
ata-HGST_HDN726060ALE614_NCHA3DZS ONLINE 0 0 0
ata-HGST_HDN726060ALE614_NCHAE5JS ONLINE 0 0 0
raidz2-6 ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HJ21DB ONLINE 0 0 0
ata-HGST_HDN726060ALE614_NCH9WUXS ONLINE 0 0 0
ata-HGST_HDN726060ALE614_NCHAXNTS ONLINE 0 0 0
ata-HGST_HDN726060ALE614_NCHA0DLS ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HJG72B ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HHX19B ONLINE 0 0 0
cache
nvme0n1 ONLINE 0 0 0
errors: No known data errors
pool: pimplepaste
state: ONLINE
scan: scrub repaired 0B in 2h38m with 0 errors on Mon Mar 19 00:17:45 2018
config:
NAME STATE READ WRITE CKSUM
pimplepaste ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1JVHTBD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1JVHVSD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1JVHT1D ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HUYA5D ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1JVDPMD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HZAZDD ONLINE 0 0 0
raidz2-1 ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1JVATKD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HZB0ND ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HY6LYD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1JT32KD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1JVAGVD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HZBL5D ONLINE 0 0 0
raidz2-2 ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HWZ1AD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HZAYJD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HZ8YMD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1JVDN8D ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HZAKPD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HWZ2ZD ONLINE 0 0 0
raidz2-3 ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HZAX7D ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1JVHD8D ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1JVG6ND ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HW7VBD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1HZBHMD ONLINE 0 0 0
ata-HGST_HDN726060ALE614_K1JVB2SD ONLINE 0 0 0
errors: No known data errors
@vbrik was ist die HW-Konfiguration dieses Systems - wie viel RAM, welches Modell der x86_64-CPU?
rincebrain
am 7. Apr. 2018
Ich kann diesen Fehler auf einem gespiegelten zpool bestätigen. Es ist ein Produktionssystem, daher habe ich vor dem Downgrade auf 0.7.6 nicht viel getestet:
pool: ssdzfs-array
state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
still be used, but some features are unavailable. [it is at the 0.6.5.11 features level]
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not support
the features. See zpool-features(5) for details.
scan: scrub repaired 0B in 0h16m with 0 errors on Sun Apr 1 01:46:59 2018
config:
NAME STATE READ WRITE CKSUM
ssdzfs-array ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-XXXX-enc ONLINE 0 0 0
ata-YYYY-enc ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
ata-ZZZZ-enc ONLINE 0 0 0
ata-QQQQ-enc ONLINE 0 0 0
errors: No known data errors
$zfs create ssdzfs-array/tmp
$(run test as previously described; fails about 1/2 the time)
$uname -a
Linux MASKED 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Ich habe versucht, den Fehler auf 0.7.6 ohne Erfolg zu reproduzieren. Hier ist eine Ausnahme von einer der Prozessor-Funktionsstufen:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
stepping : 5
microcode : 0x19
cpu MHz : 1600.000
cache size : 8192 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid dtherm ida
bogomips : 5333.51
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
[ 1.121288] microcode: CPU3 sig=0x106a5, pf=0x2, revision=0x19
tmcqueen-materials
am 7. Apr. 2018
Ich bekomme es immer noch mit primarycache=metadata beim ersten cp-Versuch:
[root<strong i="6">@zirconia</strong> ~]# zfs set primarycache=metadata storage/rhev
[root<strong i="7">@zirconia</strong> ~]# cd /storage/rhev/
[root<strong i="8">@zirconia</strong> rhev]# ls
export test
[root<strong i="9">@zirconia</strong> rhev]# cd test/
[root<strong i="10">@zirconia</strong> test]# rm -rf DST
[root<strong i="11">@zirconia</strong> test]# rm -rf SRC/*
[root<strong i="12">@zirconia</strong> test]# for i in $(seq 1 10000); do echo $i > SRC/$i ; done
[root<strong i="13">@zirconia</strong> test]# cp -r SRC DST
cp: cannot create regular file ‘DST/5269’: No space left on device
cp: cannot create regular file ‘DST/3759’: No space left on device
alexcrow1974
am 7. Apr. 2018
Für diejenigen, die auf den 0.7.7-Zweig aktualisiert haben - ist es ratsam, auf 0.7.6 zurückzustufen, bis diese Regression behoben ist?
abraunegg
am 8. Apr. 2018
Wie wird ZFS auf CentOS 7.4 heruntergestuft?
alatteri
am 8. Apr. 2018
Für Reverts mache ich normalerweise:
$ yum history (identify transaction that installed 0.7.7 over 0.7.6; yum history info XXX can be used to confirm)
$ yum history undo XXX (where XXX is the transaction number identified in the previous step)
Beachten Sie, dass ich bei dkms-Installationen nach dem Zurücksetzen normalerweise finde, dass ich Folgendes tun muss:
$ dkms remove zfs/0.7.6 -k `uname -r`
$ dkms remove spl/0.7.6 -k `uname -r`
$ dkms install spl/0.7.6 -k `uname -r` --force
$ dkms install zfs/0.7.6 -k `uname -r` --force
Um sicherzustellen, dass alle Module tatsächlich glücklich und beim Neustart ladbar sind.
tmcqueen-materials
am 8. Apr. 2018
Wird dies mit rsync anstelle von cp gesehen?
darrenfreeman
am 8. Apr. 2018
Ich kann das nicht reproduzieren, und ich habe mehrere Maschinen (Debian unstable; 0.7.7, Linux 4.15). Können Personen auch uname -srvmo ? Vielleicht spielt die Kernel-Version eine Rolle?
Linux 4.15.0-2-amd64 #1 SMP Debian 4.15.11-1 (2018-03-20) x86_64 GNU/Linux
aerusso
am 8. Apr. 2018
Ok, ich habe noch ein paar Tests gemacht.
Das System ist CentOS 7.4 x86-64 mit dem neuesten verfügbaren Kernel:
- einzelner vdev-pool: reproduziert
- gespiegelter Pool: reproduziert
- kmod und dkms: reproduziert
- zusammengestellt aus Quelle [1]: wiedergegeben
- Komprimierung lz4 und aus: reproduziert
- primärer Cache alle, Metadaten und keine: reproduziert
Auf einem Ubuntu Server 16.04 LTS mit kompiliertem 0.7.7 spl+zfs (also nicht mit der Repository-Version) kann ich den Fehler nicht reproduzieren. Nebenbei bemerkt, das Kompilieren unter Ubuntu gibt keine Warnung aus.
Das Problem scheint also auf CentOS/RHEL-Territorium beschränkt zu sein. Für mich scheint es ein Timing-/Racing-Problem zu sein (möglicherweise im Zusammenhang mit dem ARC): Alles, was die Kopierzeit erhöht, verringert die Fehlerwahrscheinlichkeit / -häufigkeit. Einige Beispiele für Maßnahmen, die die Ausfallrate senken:
cp -a(es kopiert Dateiattribute)- Cache deaktivieren
- Kopieren Sie von SRC auf ein anderes Dateisystem (zB: Root XFS). Hinweis: Dies scheint das Problem vollständig zu vermeiden.
[1]-Kompilierung gibt folgende Warnung:
/usr/src/zfs-0.7.7/module/zcommon/zfs_fletcher_avx512.o: warning: objtool: fletcher_4_avx512f_byteswap()+0x4e: can't find jump dest instruction at .text+0x171
/usr/src/zfs-0.7.7/module/zfs/vdev_raidz_math_avx512f.o: warning: objtool: mul_x2_2()+0x24: can't find jump dest instruction at .text+0x39
/usr/src/zfs-0.7.7/module/zfs/vdev_raidz_math_avx512bw.o: warning: objtool: raidz_zero_abd_cb()+0x33: can't find jump dest instruction at .text+0x3d
@shodanshok Es tut mir leid, ich habe große Probleme, diese Information aufzuspüren. kernel-3.10.0-693.21.1.el7.x86_64 .
Hat jemand dieses Problem mit "neueren" Mainline-Kerneln (wie 4.x)?
aerusso
am 8. Apr. 2018
Grüße,
Ich habe Spiegel mit dem gleichen Problem.
Scientific Linux 7.4 (vollständig aktualisiert)
zfs-0.7.7 aus den Repos von zfsonlinux.org
$ uname -srvmo
Linux 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 13:12:24 CST 2018 x86_64 GNU/Linux
Die Ausgabe meiner Yum-Installation:
Running transaction
Installing : kernel-devel-3.10.0-693.21.1.el7.x86_64 1/10
Installing : kernel-headers-3.10.0-693.21.1.el7.x86_64 2/10
Installing : glibc-headers-2.17-196.el7_4.2.x86_64 3/10
Installing : glibc-devel-2.17-196.el7_4.2.x86_64 4/10
Installing : gcc-4.8.5-16.el7_4.2.x86_64 5/10
Installing : dkms-2.4.0-1.20170926git959bd74.el7.noarch 6/10
Installing : spl-dkms-0.7.7-1.el7_4.noarch 7/10
Loading new spl-0.7.7 DKMS files...
Building for 3.10.0-693.21.1.el7.x86_64
Building initial module for 3.10.0-693.21.1.el7.x86_64
Done.
spl:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/3.10.0-693.21.1.el7.x86_64/extra/spl/spl/
splat.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/3.10.0-693.21.1.el7.x86_64/extra/splat/splat/
Adding any weak-modules
depmod....
DKMS: install completed.
Installing : zfs-dkms-0.7.7-1.el7_4.noarch 8/10
Loading new zfs-0.7.7 DKMS files...
Building for 3.10.0-693.21.1.el7.x86_64
Building initial module for 3.10.0-693.21.1.el7.x86_64
Done.
zavl:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/3.10.0-693.21.1.el7.x86_64/extra/avl/avl/
znvpair.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/3.10.0-693.21.1.el7.x86_64/extra/nvpair/znvpair/
zunicode.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/3.10.0-693.21.1.el7.x86_64/extra/unicode/zunicode/
zcommon.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/3.10.0-693.21.1.el7.x86_64/extra/zcommon/zcommon/
zfs.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/3.10.0-693.21.1.el7.x86_64/extra/zfs/zfs/
zpios.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/3.10.0-693.21.1.el7.x86_64/extra/zpios/zpios/
icp.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/3.10.0-693.21.1.el7.x86_64/extra/icp/icp/
Adding any weak-modules
depmod....
DKMS: install completed.
Installing : spl-0.7.7-1.el7_4.x86_64 9/10
Installing : zfs-0.7.7-1.el7_4.x86_64 10/10
Verifying : dkms-2.4.0-1.20170926git959bd74.el7.noarch 1/10
Verifying : zfs-dkms-0.7.7-1.el7_4.noarch 2/10
Verifying : zfs-0.7.7-1.el7_4.x86_64 3/10
Verifying : spl-0.7.7-1.el7_4.x86_64 4/10
Verifying : kernel-devel-3.10.0-693.21.1.el7.x86_64 5/10
Verifying : glibc-devel-2.17-196.el7_4.2.x86_64 6/10
Verifying : kernel-headers-3.10.0-693.21.1.el7.x86_64 7/10
Verifying : gcc-4.8.5-16.el7_4.2.x86_64 8/10
Verifying : spl-dkms-0.7.7-1.el7_4.noarch 9/10
Verifying : glibc-headers-2.17-196.el7_4.2.x86_64 10/10
Installed:
zfs.x86_64 0:0.7.7-1.el7_4
Dependency Installed:
dkms.noarch 0:2.4.0-1.20170926git959bd74.el7 gcc.x86_64 0:4.8.5-16.el7_4.2
glibc-devel.x86_64 0:2.17-196.el7_4.2 glibc-headers.x86_64 0:2.17-196.el7_4.2
kernel-devel.x86_64 0:3.10.0-693.21.1.el7 kernel-headers.x86_64 0:3.10.0-693.21.1.el7
spl.x86_64 0:0.7.7-1.el7_4 spl-dkms.noarch 0:0.7.7-1.el7_4
zfs-dkms.noarch 0:0.7.7-1.el7_4
Complete!
Ich benutze rsnapshot, um Backups zu machen. Wenn das Äquivalent zu unten ausgeführt wird, treten Probleme auf.
$ /usr/bin/cp -al /bkpfs/Rsnapshot/hourly.0 /bkpfs/Rsnapshot/hourly.1
/usr/bin/cp: cannot create hard link ‘/bkpfs/Rsnapshot/hourly.1/System/home/user/filename’ to ‘/bkpfs/Rsnapshot/hourly.0/System/home/user/filename’: No space left on device
Es gibt viel Platz
$ df -h /bkpfs/
Filesystem Size Used Avail Use% Mounted on
bkpfs 5.0T 4.2T 776G 85% /bkpfs
$ df -i /bkpfs/
Filesystem Inodes IUsed IFree IUse% Mounted on
bkpfs 1631487194 5614992 1625872202 1% /bkpfs
zpool iostat -v bkpfs
capacity operations bandwidth
pool alloc free read write read write
---------------------------------------------- ----- ----- ----- ----- ----- -----
bkpfs 4.52T 950G 9 5 25.4K 117K
mirror 1.84T 912G 4 3 22.0K 94.7K
ata-Hitachi_HUA723030ALA640 - - 2 1 11.2K 47.4K
ata-Hitachi_HUA723030ALA640 - - 2 1 10.8K 47.4K
mirror 2.68T 37.3G 4 2 3.46K 22.2K
ata-Hitachi_HUA723030ALA640 - - 2 1 1.71K 11.1K
ata-Hitachi_HUA723030ALA640 - - 2 1 1.75K 11.1K
cache - - - - - -
ata-INTEL_SSDSC2BW120H6 442M 111G 17 0 9.48K 10.0K
---------------------------------------------- ----- ----- ----- ----- ----- -----
zpool status
pool: bkpfs
state: ONLINE
scan: scrub repaired 0B in 11h17m with 0 errors on Sun Apr 1 05:34:09 2018
config:
NAME STATE READ WRITE CKSUM
bkpfs ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-Hitachi_HUA723030ALA640 ONLINE 0 0 0
ata-Hitachi_HUA723030ALA640 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
ata-Hitachi_HUA723030ALA640 ONLINE 0 0 0
ata-Hitachi_HUA723030ALA640 ONLINE 0 0 0
cache
ata-INTEL_SSDSC2BW120H6 ONLINE 0 0 0
errors: No known data errors
zfs get all bkpfs
NAME PROPERTY VALUE SOURCE
bkpfs type filesystem -
bkpfs creation Fri Dec 22 10:34 2017 -
bkpfs used 4.52T -
bkpfs available 776G -
bkpfs referenced 4.19T -
bkpfs compressratio 1.00x -
bkpfs mounted yes -
bkpfs quota none default
bkpfs reservation none default
bkpfs recordsize 128K default
bkpfs mountpoint /bkpfs default
bkpfs sharenfs off default
bkpfs checksum on default
bkpfs compression off default
bkpfs atime on default
bkpfs devices on default
bkpfs exec on default
bkpfs setuid on default
bkpfs readonly off default
bkpfs zoned off default
bkpfs snapdir hidden default
bkpfs aclinherit restricted default
bkpfs createtxg 1 -
bkpfs canmount on default
bkpfs xattr on default
bkpfs copies 1 default
bkpfs version 5 -
bkpfs utf8only off -
bkpfs normalization none -
bkpfs casesensitivity sensitive -
bkpfs vscan off default
bkpfs nbmand off default
bkpfs sharesmb off default
bkpfs refquota none default
bkpfs refreservation none default
bkpfs guid 8662648373298485368 -
bkpfs primarycache all default
bkpfs secondarycache all default
bkpfs usedbysnapshots 334G -
bkpfs usedbydataset 4.19T -
bkpfs usedbychildren 234M -
bkpfs usedbyrefreservation 0B -
bkpfs logbias latency default
bkpfs dedup off default
bkpfs mlslabel none default
bkpfs sync standard default
bkpfs dnodesize legacy default
bkpfs refcompressratio 1.00x -
bkpfs written 1.38T -
bkpfs logicalused 4.51T -
bkpfs logicalreferenced 4.18T -
bkpfs volmode default default
bkpfs filesystem_limit none default
bkpfs snapshot_limit none default
bkpfs filesystem_count none default
bkpfs snapshot_count none default
bkpfs snapdev hidden default
bkpfs acltype off default
bkpfs context none default
bkpfs fscontext none default
bkpfs defcontext none default
bkpfs rootcontext none default
bkpfs relatime off default
bkpfs redundant_metadata all default
bkpfs overlay off default
Für diejenigen, die meine Hardware kennenlernen möchten, das System ist ein AMD X2 255-Prozessor mit 8 GB Speicher (bisher mehr als genug für mein Heim-Backup-System).
Ich kann heute zurückkehren, oder ich kann beim Testen helfen, wenn mich jemand braucht, um etwas auszuprobieren. Lass es mich wissen.
Danke!
cstackpole
am 8. Apr. 2018
Kann jemand, der das reproduzieren kann, versuchen, die Änderungen zwischen 0.7.6 und 0.7.7 zu halbieren, damit wir sehen können, welcher Commit die Leute kaputt macht?
rincebrain
am 8. Apr. 2018
Höchstwahrscheinlich https://github.com/zfsonlinux/zfs/commit/cc63068e95ee725cce03b1b7ce50179825a6cda5, scheint eine Race-Condition in der mzap->fzap-Upgrade-Phase zu sein.
loli10K
am 8. Apr. 2018
@loli10K , das, äh, scheint schrecklich genug, dass, wenn nicht jemand freiwillig eine Lösung für das Rennen Real Fast bereitstellt, ein Zurücksetzen und das Abschneiden einer Punktfreigabe allein dafür verdient zu sein scheint, zumindest für mich.
rincebrain
am 8. Apr. 2018
@rincebrain Ich kann es später heute versuchen. Ich treffe mich mit ein paar Freunden zum Mittagessen und werde für ein paar Stunden weg sein, aber ich helfe gerne, wie ich kann, wenn ich zurückkomme.
[Bearbeiten] Um zu versuchen, die Änderungen zu halbieren. :-)
cstackpole
am 8. Apr. 2018
@cstackpole Wenn Sie dies tun, lohnt es sich wahrscheinlich, es mit und ohne den Commit @ loli10K zu versuchen, auf den gezeigt wird, anstatt ihn von der Bisect natürlich finden zu lassen.
rincebrain
am 8. Apr. 2018
Nach dem, was wir bisher gesehen haben, scheint es sicherlich nur ältere (womit ich meine niedriger versionierte) Kernel zu betreffen. Ich konnte das Problem unter Linux 4.15 (Fedora) nicht reproduzieren.
Ringdingcoder
am 8. Apr. 2018
@aerusso
[root<strong i="7">@localhost</strong> test]# uname -a
Linux localhost.localdomain 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
@ loli10K irgendein Hinweis darauf, warum es nur 3.x-Kernel betrifft, während 4.x immun zu sein scheint?
shodanshok
am 8. Apr. 2018
Übrigens, ich habe es halbiert und konnte es unter CentOS 7 mit 3.10.0-693.21.1 auf eb9c453 nicht reproduzieren, konnte es aber auf cc63068, also scheint dies die Ursache zu sein.
rincebrain
am 8. Apr. 2018
Ich habe noch keine Tests durchgeführt, aber ich schätze die Geschwindigkeit sehr, mit der Sie den Commit gefunden haben, Hirngespinst! Seit ich dieses Problem gesehen habe, bin ich ziemlich nervös und weiß noch nicht, ob ich betroffen bin.
darrenfreeman
am 8. Apr. 2018
% uname -srvmo
Linux 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 UTC 2018 x86_64 GNU/Linux
alatteri
am 8. Apr. 2018
Da dies FRAME_POINTER-spezifisch zu sein scheint (es sei denn, jemand hat ein Gegenbeispiel), würde ich vermuten, dass dies # 5041 2.0: Elec boogalootric ist
rincebrain
am 8. Apr. 2018
Danke @rincebrain für die Bestätigung!
Da dies nur mein persönliches System zu Hause ist, habe ich nichts dagegen, es in seinem reproduzierbaren Zustand zu belassen, wenn jemand möchte, dass ich später in der Woche etwas teste.
cstackpole
am 8. Apr. 2018
@kpande Ja, ich habe diesen verfolgt, aber überhaupt nicht darauf geachtet. Wurde dies sicher auf cc63068e95ee725cce03b1b7ce50179825a6cda5 eingegrenzt? Dies ist eindeutig etwas, das sofort behoben werden muss.
dweeezil
am 9. Apr. 2018
@dweeezil Ich konnte es nicht ohne weiteres auf CentOS 7 x86_64 auf dem Commit vor cc63068 reproduzieren und konnte es leicht auf cc63068 reproduzieren, beide Male dieselbe SPL.
rincebrain
am 9. Apr. 2018
cc63068 legt eine Grenze dafür fest, wie oft zap_add versucht, einen Zap-Blattblock für ein Verzeichnis zu erweitern (zu teilen), wenn das Hinzufügen eines neuen Eintrags ein vorhandenes Blatt überlaufen lassen würde.
Das Limit (2) reicht aus, um einen kollidierenden Namen zu behandeln, wenn casesensitivity=sensitive gesetzt ist, scheint aber zu früh abzuspringen (mit ENOSPC ), wenn der Zap für das Verzeichnis eine bestimmte Größe überschreitet ( möglicherweise auch aufgrund von Leaf-Hash-Kollisionen). Wenn zap_add fehlschlägt, wird die Transaktion zurückgesetzt, sodass der Znode für die neue Datei entfernt wird.
Dies ist bisher unerwünscht, führt aber per se nicht zu Datenverlust, da das System mit „No space left on device“ lediglich das Anlegen neuer Dateien verweigert.
Meine Hypothese ist, dass ein nachfolgendes zap_add s erfolgreich ist, da der Zap des Verzeichnisses bereits gewachsen ist (solange ein bis zwei zusätzliche Blattaufteilungen ausreichen, um in den neuen Eintrag zu passen), aber die nachfolgenden Zap-Erweiterungen verworfen werden, aufgrund eines Nebeneffekts des vorangegangenen Rollbacks (womöglich dort die Transaktion schließen). Der vfs-Seitencache spiegelt immer noch die neuen Dateien wider, aber sie sind nicht in ARC vorhanden (oder auf der Festplatte festgeschrieben), daher werden sie durch das Leeren des Seitencaches entfernt. Es ist nicht klar, ob die Znodes für die Dateien dadurch geleakt werden (nicht mit dem Verzeichnis verknüpft, aber immer noch vorhanden) oder ob sie ebenfalls verworfen werden.
trisk
am 9. Apr. 2018
Ich habe 0.7.7 aufgrund dieses Problems in Gentoo maskiert.
https://bugs.gentoo.org/652828
Ich habe meinen Zeitplan für morgen gelöscht, damit ich Zeit dafür habe. Ich würde mehr sagen, aber das hat mich blind gemacht, und es ist zu spät in der Nacht, um mich jetzt damit zu beschäftigen.
ryao
am 9. Apr. 2018
Ok, das erweiterte Wiederholungslimit 2 ist also nicht genug. Tatsächlich sollte es überhaupt kein Limit geben, bis wir das Limit von ZAP selbst erreicht haben.
Der Grund, warum Sie einen ZAP mit vielen Dateien erstellen, aber nicht kopieren können, liegt darin, dass Sie beim Erstellen einer Datei eine zufällige Datei in Bezug auf den Hash-Wert erstellen. Wenn Sie jedoch Dateien von einem Verzeichnis in ein anderes Verzeichnis kopieren, erstellen Sie Dateien sequentiell in Bezug auf den Hash-Wert. Das heißt, wenn das Quellverzeichnis seine Blätter 6 Mal erweitert hat, müssen Sie die Zielblätter 6 Mal auf einmal erweitern.
Eine Sache, die zu beachten ist, ist, dass wir unterschiedliche Salze für unterschiedliche Verzeichnisse verwenden, also sollte theoretisch ein ausreichend starkes Salz dies verhindern. Dies zeigt, dass das aktuelle Salz nicht stark genug ist.
Um das Erweiterungslimit zu entfernen, versuchen Sie, diesen if-Block zu entfernen.
https://github.com/zfsonlinux/zfs/blob/cc63068e95ee725cce03b1b7ce50179825a6cda5/module/zfs/zap.c#L861
Die danach fehlende Datei ist ein seltsames Problem. Ich muss nachforschen, um zu sehen, was passiert ist. Ich glaube nicht, dass es im Fehlerpfad ein Transaktions-Rollback gibt.
tuxoko
am 9. Apr. 2018
Das Aufheben des Limits bringt die Box nicht in Panik, wenn die casenorm ZTS-Gruppe ausgeführt wird, und scheint dieses Problem zu verhindern:
@@ -855,15 +855,6 @@ retry:
if (err == 0) {
zap_increment_num_entries(zap, 1, tx);
} else if (err == EAGAIN) {
- /*
- * If the last two expansions did not help, there is no point
- * trying to expand again
- */
- if (expand_retries > MAX_EXPAND_RETRIES && prev_l == l) {
- err = SET_ERROR(ENOSPC);
- goto out;
- }
-
err = zap_expand_leaf(zn, l, tag, tx, &l);
zap = zn->zn_zap; /* zap_expand_leaf() may change zap */
if (err == 0) {
[root<strong i="9">@centos</strong> ~]# lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.4.1708 (Core)
Release: 7.4.1708
Codename: Core
[root<strong i="10">@centos</strong> ~]# uname -r
3.10.0-693.21.1.el7.x86_64
[root<strong i="11">@centos</strong> ~]# cat /sys/module/zfs/version
0.7.7-1
[root<strong i="12">@centos</strong> ~]# while :; do
> zpool destroy testpool
> zpool create testpool -f -O xattr=dir -O atime=off -O mountpoint=none -O recordsize=1M /dev/vdb
> zfs create testpool/src -o mountpoint=/mnt
> zfs create testpool/dst -o mountpoint=/mnt/DST
> mkdir /mnt/SRC; for i in $(seq 1 10000); do echo -n > /mnt/SRC/$i; done;
> printf "$(find /mnt/SRC -type f | wc -l) -> "
> cp -r /mnt/SRC /mnt/DST
> echo "$(find /mnt/DST -type f | wc -l)"
> done
10000 -> 10000
10000 -> 10000
10000 -> 10000
10000 -> 10000
10000 -> 10000
10000 -> 10000
10000 -> 10000
10000 -> 10000
10000 -> 10000
10000 -> 10000
10000 -> 10000
10000 -> 10000
10000 -> 10000
10000 -> 10000
10000 -> 10000
^C
[root<strong i="13">@centos</strong> ~]#
...
[root<strong i="14">@centos</strong> ~]# sudo -u nobody -s /usr/share/zfs/zfs-tests.sh -d /var/tmp -T casenorm
Test: /usr/share/zfs/zfs-tests/tests/functional/casenorm/setup (run as root) [00:00] [PASS]
Test: /usr/share/zfs/zfs-tests/tests/functional/casenorm/case_all_values (run as root) [00:00] [PASS]
Test: /usr/share/zfs/zfs-tests/tests/functional/casenorm/norm_all_values (run as root) [00:01] [PASS]
Test: /usr/share/zfs/zfs-tests/tests/functional/casenorm/mixed_create_failure (run as root) [00:10] [PASS]
Test: /usr/share/zfs/zfs-tests/tests/functional/casenorm/cleanup (run as root) [00:00] [PASS]
Results Summary
PASS 5
Running Time: 00:00:12
Percent passed: 100.0%
Log directory: /var/tmp/test_results/20180401T016189
[root<strong i="15">@centos</strong> ~]#
Testen Sie jetzt den Kernel 3.10.x auf Debian 8 mit der gleichen Kconfig aus der vorherigen CentOS7-Box ... EDIT: Debian bleibt stark und scheint nicht betroffen zu sein, wenn es 3.10.108 ausführt.
loli10K
am 9. Apr. 2018
Ich kann bestätigen, dass ENOSPC (No space left on device) von fzap_add_cd kommt, wenn wir das Retry-Limit erreichen und den Reproduzierer unter dem folgenden Stap-Skript ausführen:
probe
module("zfs").function("zap_leaf_split").call,
module("zfs").function("fzap_add_cd").call,
module("zfs").function("mzap_upgrade").call,
module("zfs").function("zap_entry_create").call,
module("zfs").function("zap_expand_leaf").call
{
printf(" %s -> %s\n", symname(caller_addr()), ppfunc());
}
probe
module("zfs").function("zap_leaf_split").return,
module("zfs").function("fzap_add_cd").return,
module("zfs").function("mzap_upgrade").return,
module("zfs").function("zap_entry_create").return,
module("zfs").function("zap_expand_leaf").return
{
printf(" %s <- %s %s\n", symname(caller_addr()), ppfunc(), $$return$);
}
probe
module("zfs").statement("fzap_add_cd@module/zfs/zap.c:867")
{
printf(" * %s <- %s expand_retries=%s\n", symname(caller_addr()), ppfunc(), $expand_retries$$);
}
````
relevant output
fzap_add_cd -> zap_entry_create
0xffffffff816b9459 <- zap_entry_create return=11
- 0xffffffff816b9459 <- fzap_add_cd expand_retries=0
fzap_add_cd -> zap_expand_leaf
zap_expand_leaf -> zap_leaf_split
0xffffffff816b9459 <- zap_leaf_split
0xffffffff816b9459 <- zap_expand_leaf return=0
fzap_add_cd -> zap_entry_create
0xffffffff816b9459 <- zap_entry_create return=11 - 0xffffffff816b9459 <- fzap_add_cd expand_retries=1
fzap_add_cd -> zap_expand_leaf
zap_expand_leaf -> zap_leaf_split
0xffffffff816b9459 <- zap_leaf_split
0xffffffff816b9459 <- zap_expand_leaf return=0
fzap_add_cd -> zap_entry_create
0xffffffff816b9459 <- zap_entry_create return=11 - 0xffffffff816b9459 <- fzap_add_cd expand_retries=2
fzap_add_cd -> zap_expand_leaf
zap_expand_leaf -> zap_leaf_split
0xffffffff816b9459 <- zap_leaf_split
0xffffffff816b9459 <- zap_expand_leaf return=0
fzap_add_cd -> zap_entry_create
0xffffffff816b9459 <- zap_entry_create return=11 - 0xffffffff816b9459 <- fzap_add_cd expand_retries=3
zap_add_impl <- fzap_add_cd return=28 (ENOSPC)
```
loli10K
am 9. Apr. 2018
Nun, ich konnte diesen laufenden CentOS7-Kernel nicht auf Debian8 reproduzieren, sondern mit seinem cp :
Unter CentOS7 auch mit cp von Debian8 testen:
[root<strong i="9">@centos</strong> ~]# while :; do
> zpool destroy testpool
> zpool create testpool -f -O xattr=dir -O atime=off -O mountpoint=none -O recordsize=1M /dev/vdb
> zfs create testpool/src -o mountpoint=/mnt
> zfs create testpool/dst -o mountpoint=/mnt/DST
> mkdir /mnt/SRC; for i in $(seq 1 10000); do echo -n > /mnt/SRC/$i; done;
> ./debian-cp -r /mnt/SRC /mnt/DST-debian
> cp -r /mnt/SRC /mnt/DST-centos
> done
cp: cannot create regular file ‘/mnt/DST-centos/4143’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/1970’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/5654’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/5945’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/2740’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/3659’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/2070’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/5183’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/7715’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/8593’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/9654’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/1064’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/2862’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/6636’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/865’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/6090’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/6066’: No space left on device
cp: cannot create regular file ‘/mnt/DST-centos/9233’: No space left on device
^C
[root<strong i="10">@centos</strong> ~]# lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.4.1708 (Core)
Release: 7.4.1708
Codename: Core
[root<strong i="11">@centos</strong> ~]# rpm -qa coreutils
coreutils-8.22-18.el7.x86_64
[root<strong i="12">@centos</strong> ~]#
Unter Debian8 mit cp von CentOS7:
root<strong i="7">@linux</strong>:~# while :; do
> zpool destroy testpool
> zpool create testpool -f -O xattr=dir -O atime=off -O mountpoint=none -O recordsize=1M /dev/vdb
> zfs create testpool/src -o mountpoint=/mnt
> zfs create testpool/dst -o mountpoint=/mnt/DST
> mkdir /mnt/SRC; for i in $(seq 1 10000); do echo -n > /mnt/SRC/$i; done;
> cp -r /mnt/SRC /mnt/DST-debian
> ./centos-cp -r /mnt/SRC /mnt/DST-centos
> done
./centos-cp: cannot create regular file ‘/mnt/DST-centos/5423’: No space left on device
./centos-cp: cannot create regular file ‘/mnt/DST-centos/8558’: No space left on device
./centos-cp: cannot create regular file ‘/mnt/DST-centos/4338’: No space left on device
./centos-cp: cannot create regular file ‘/mnt/DST-centos/3524’: No space left on device
./centos-cp: cannot create regular file ‘/mnt/DST-centos/4601’: No space left on device
./centos-cp: cannot create regular file ‘/mnt/DST-centos/9311’: No space left on device
./centos-cp: cannot create regular file ‘/mnt/DST-centos/7348’: No space left on device
./centos-cp: cannot create regular file ‘/mnt/DST-centos/3211’: No space left on device
./centos-cp: cannot create regular file ‘/mnt/DST-centos/8768’: No space left on device
./centos-cp: cannot create regular file ‘/mnt/DST-centos/6951’: No space left on device
./centos-cp: cannot create regular file ‘/mnt/DST-centos/4538’: No space left on device
./centos-cp: cannot create regular file ‘/mnt/DST-centos/7596’: No space left on device
./centos-cp: cannot create regular file ‘/mnt/DST-centos/7539’: No space left on device
^C
root<strong i="8">@linux</strong>:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.0 (jessie)
Release: 8.0
Codename: jessie
root<strong i="9">@linux</strong>:~# dpkg -l coreutils
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============================================-============================-============================-==================================================================================================
ii coreutils 8.23-4 amd64 GNU core utilities
root<strong i="10">@linux</strong>:~#
Möglicherweise müssen wir für den in #7411 vorgeschlagenen Regressionstest einen besseren Reproduzierer als "cp" finden.
loli10K
am 9. Apr. 2018
Dieses Update wird immer noch angeboten, wenn RHEL-basierte Systeme ein "Yum-Update" durchführen; Sollte das Update angesichts der schwerwiegenden Natur dieses Fehlers nicht zurückgezogen werden und 0.7.6 als neueste verfügbare Version übrig bleiben?
Heute ist ein Tag, an dem ich EXTREM froh bin, dass ich ZFS/SPL-Updates blockiert habe und sie manuell während bestimmter Ausfallzeiten oder zu anderen günstigeren Zeiten durchführe.
flynnjFIU
am 9. Apr. 2018
@flynnjFIU @behlendorf ist der Maintainer für RHEL-basierte Systeme und er ist gerade ins Büro gekommen. Wahrscheinlich weiß er noch nicht einmal davon. Ich werde ihn anrufen, um ihn zu informieren, damit er das Update aus dem RPM-Repository entfernen kann. Danke für den Hinweis.
@perfinion wies mich im IRC darauf hin, dass dies möglicherweise hauptsächlich nur auf RHEL-basierten Systemen reproduzierbar ist, da sie xattr=sa verwenden, um die Handhabung von Dateisystemlabels durch SELinux zu beschleunigen. xattr=sa könnte verwandt sein. Ich hatte heute etwas spät damit angefangen, also bin ich mir zu diesem Zeitpunkt so oder so nicht sicher, aber ich denke, dass er einen guten Punkt gemacht hat, dass die Interaktion mit xattr=sa in Betracht gezogen werden sollte.
ryao
am 9. Apr. 2018
@ryao dasselbe Problem tritt bei xatrr=on .
vbrik
am 9. Apr. 2018
@flynnjFIU Ich habe mit Brian gesprochen. Er hat das erst in etwa der letzten Stunde erfahren. Der vorläufige Plan ist, 0.7.7 aus dem RPM-Repository zu ziehen und 0.7.8 mit einem Revert von cc63068e95ee725cce03b1b7ce50179825a6cda5 herauszubringen. Er wird sich mit @tonyhutter unterhalten, bevor er den Plan zum Umgang damit fertigstellt.
ryao
am 9. Apr. 2018
@vbrik Danke für diese Informationen. Das hilft, die Dinge einzugrenzen. :)
ryao
am 9. Apr. 2018
@ryao Besteht die Gefahr, dass Daten, die mit 0.7.7 unter CentOS erstellt wurden, mit dem Fix in 0.7.8 beschädigt werden/verschwinden?
alatteri
am 9. Apr. 2018
@alatteri Mein vorläufiges Verständnis ist, dass die Daten in Ordnung sein sollten, wenn ENOSPC nicht aufgetreten ist. Ich schlage jedoch vor, vorerst auf 0.7.6 herunterzustufen.
ryao
am 9. Apr. 2018
Würden Personen, die dieses Problem reproduzieren können/nicht können, diese Informationen zu den getesteten Systemen veröffentlichen?
- Reproduzierbarkeit (ja oder nein)
- ZoL-Version
- Distributionsname und Version
- Kernelversion
- Coreutils-Version
- SELinux-Status (Erzwingen, Freigeben, Aus/Nicht verwendet)
ryao
am 9. Apr. 2018
Für diejenigen, die sie benötigen, finden Sie hier Links zu den RPM-Paketen für Coreutils unter CentOS 6 und CentOS 7:
https://centos.pkgs.org/6/centos-x86_64/coreutils-8.4-46.el6.x86_64.rpm.html
https://centos.pkgs.org/7/centos-x86_64/coreutils-8.22-18.el7.x86_64.rpm.html
Sie enthalten die unter CentOS verwendeten cp . Anweisungen zum Extrahieren finden Sie hier:
https://www.cyberciti.biz/tips/how-to-extract-an-rpm-package- without-installing-it.html
ryao
am 9. Apr. 2018
Compiler: gcc Version 6.4.0 (Gentoo Hardened 6.4.0-r1 p1.3)
uname -a: Linux baraddur 4.16.0-gentoo #1 SMP PREEMPT Wed Apr 4 12:18:23 +08 2018 x86_64 AMD Ryzen Threadripper 1950X 16-Core Processor AuthenticAMD GNU/Linux
Distribution: Gentoo Hardened Selinux
ZFS kmod von HEAD: Geladenes Modul v0.7.0-403_g1724eb62
SELinux Enforcing und Permissive haben es beide getroffen
gentoo cp 8.28-r1 Binary: Repro auch mit 100.000 Dateien nicht möglich
debian 8 8.26 binär: Kann auch nicht reproduziert werden
centos7 8.22 binär: trifft es sofort
perfinion
am 9. Apr. 2018
Reproduzierbarkeit: ja
ZoL-Version: zfs-0.7.7-1.el6.x86_64
Name und Version der Distribution: Scientific Linux 6.8
Kernel-Version: 2.6.32-696.23.1.el6.x86_64
Coreutils-Version: coreutils-8.4-46.el6.x86_64
SELinux-Status: aus
vbrik
am 9. Apr. 2018
Reproduzierbarkeit: nein
Name und Version der Distribution: Arch Linux
ZoL-Version:
local/spl-linux-git 2018.04.04.r1070.581bc01.4.15.15.1-1 (archzfs-linux-git)
local/spl-utils-common-git 2018.04.04.r1070.581bc01-1 (archzfs-linux-git)
local/zfs-linux-git 2018.04.04.r3402.533ea0415.4.15.15.1-1 (archzfs-linux-git)
local/zfs-utils-common-git 2018.04.04.r3402.533ea0415-1 (archzfs-linux-git)
Dies ist ein ZFS-Build, der aus dem Commit 533ea0415 erstellt wurde.
Kernel-Version: Linux kiste 4.15.15-1-ARCH #1 SMP PREEMPT Sat Mar 31 23:59:25 UTC 2018 x86_64 GNU/Linux
Coreutils-Version: local/coreutils 8.29-1
SELinux-Status (Erzwingen, Freigeben, Aus/Nicht verwendet): Aus
CentOS 7 cp kann aufgrund der Abhängigkeit von SELinux-Bibliotheken nicht getestet werden (Arch unterstützt SELinux nicht).
UweSauter
am 9. Apr. 2018
@tuxoko Schöne Analyse!
Der Grund, warum Sie einen ZAP mit vielen Dateien erstellen, aber nicht kopieren können, liegt darin, dass Sie beim Erstellen einer Datei eine zufällige Datei in Bezug auf den Hash-Wert erstellen. Wenn Sie jedoch Dateien von einem Verzeichnis in ein anderes Verzeichnis kopieren, erstellen Sie Dateien sequentiell in Bezug auf den Hash-Wert. Das heißt, wenn das Quellverzeichnis seine Blätter 6 Mal erweitert hat, müssen Sie die Zielblätter 6 Mal auf einmal erweitern.
Eine Sache, die zu beachten ist, ist, dass wir unterschiedliche Salze für unterschiedliche Verzeichnisse verwenden, also sollte theoretisch ein ausreichend starkes Salz dies verhindern. Dies zeigt, dass das aktuelle Salz nicht stark genug ist.
Das Salz ist ziemlich schwach (siehe mzap_create_impl() ); Ich bin mir nicht sicher, warum wir nicht einfach random_get_pseudo_bytes() verwendet haben. Ich frage mich, ob sie tatsächlich genau den gleichen Hasch erhalten oder ob es eine Schwäche in der Art und Weise gibt, wie das Salz in zap_hash() verwendet wird? zdb kann das Salz ausgeben, um zu sehen, ob sie gleich sind.
ahrens
am 9. Apr. 2018
- Reproduzierbar = ja
- zfs.x86_64 0.7.7-1.el7_4 @zfs-kmod
- CentOS 7.4
- Linux 3.10.0-693.21.1.el7.x86_64 x86_64 GNU/Linux
- coreutils.x86_64 8.22-18.el7
- SELINUX=deaktiviert. SELINUXTYPE=gezielt
alatteri
am 9. Apr. 2018
Wir arbeiten daran, eine Version 0.7.8 herauszubringen, wobei https://github.com/zfsonlinux/zfs/commit/cc63068e95ee725cce03b1b7ce50179825a6cda5 so schnell wie möglich zurückgesetzt wird.
tonyhutter
am 9. Apr. 2018
Bevor irgendjemand anfängt, Binärdateien bindiff einzulesen: CentOS cp open(O_CREAT) ist randomisiert, Debian nicht: zufällige Dateireihenfolge = zufällige Hash-Werte = eher zap_expand_leaf() / zap_leaf_split() denke ich ...
[root<strong i="10">@centos</strong> ~]# grep DST /tmp/debian.txt | head -n 100
execve("./debian-cp", ["./debian-cp", "-r", "/mnt/SRC", "/mnt/DST-debian"], [/* 18 vars */]) = 0
stat("/mnt/DST-debian", 0x7ffc25990cb0) = -1 ENOENT (No such file or directory)
lstat("/mnt/DST-debian", 0x7ffc25990a40) = -1 ENOENT (No such file or directory)
mkdir("/mnt/DST-debian", 0755) = 0
lstat("/mnt/DST-debian", {st_mode=S_IFDIR|0755, st_size=2, ...}) = 0
open("/mnt/DST-debian/3357", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3358", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3359", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3360", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3361", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3362", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3363", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3364", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3365", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3366", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3367", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3368", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3369", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3370", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3371", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3372", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3373", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3374", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3375", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3376", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3377", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3378", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3379", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3380", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3381", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3382", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3383", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3384", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3385", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3386", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3387", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3388", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3389", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3390", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3391", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3392", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3393", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3394", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3395", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/1", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/2", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/3", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/4", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/5", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/6", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/7", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/8", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/9", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/10", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/11", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/12", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/13", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/14", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/15", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/16", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/17", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/18", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/19", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/20", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/21", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/22", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/23", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/24", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/25", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/26", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/27", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/28", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/29", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/30", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/31", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/32", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/33", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/34", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/35", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/36", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/37", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/38", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/39", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/40", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/41", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/42", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/43", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/44", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/45", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/46", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/47", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/48", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/49", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/50", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/51", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/52", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/53", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/54", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/55", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-debian/56", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
[root<strong i="11">@centos</strong> ~]# grep DST /tmp/centos.txt | head -n 100
execve("/bin/cp", ["cp", "-r", "/mnt/SRC", "/mnt/DST-centos"], [/* 18 vars */]) = 0
stat("/mnt/DST-centos", 0x7ffc6299e1d0) = -1 ENOENT (No such file or directory)
lstat("/mnt/DST-centos", 0x7ffc6299df30) = -1 ENOENT (No such file or directory)
mkdir("/mnt/DST-centos", 0755) = 0
lstat("/mnt/DST-centos", {st_mode=S_IFDIR|0755, st_size=2, ...}) = 0
open("/mnt/DST-centos/6667", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4153", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/8772", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/2455", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/8691", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/6784", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/2422", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/8705", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/2878", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4124", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/6610", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/2558", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/2896", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/2902", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/2975", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/8608", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4029", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/6689", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/9017", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/5636", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/688", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/1590", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/7102", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/9183", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/1404", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/7096", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/3330", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/3347", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/1473", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/7175", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/5641", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/1829", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/9060", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/611", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/1509", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/1953", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/785", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/7078", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/1924", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/666", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/2065", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4939", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4563", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/6257", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/8342", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/8335", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/6220", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/2186", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4514", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/2012", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4480", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/2168", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4834", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4843", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/8238", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4419", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/7968", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/3700", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/5392", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/1034", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/9427", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/7532", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/3694", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/5206", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/5271", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/7545", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/9450", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/1043", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/3777", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/3799", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/7865", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/221", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/9970", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/1139", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/256", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/9907", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/7812", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/7448", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/9893", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/7986", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4944", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/2018", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4933", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4569", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/8348", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4849", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/2115", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4587", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/8232", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/6327", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/2081", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4413", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/4464", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/6350", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
open("/mnt/DST-centos/8245", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
[root<strong i="12">@centos</strong> ~]#
Würde jemand mit einem System der CentOS-Familie bitte gdb und coreutils-debuginfo installieren. Führen Sie dann gdb -ex 'info sources' $(which cp) aus und posten Sie die Ausgabe für mich? Es wird mir einige Mühe ersparen, ein System in die Hände zu bekommen, damit ich versuchen kann, herauszufinden, was der Unterschied zwischen cp von CentOS und $#$ cp $#$ von Gentoo ist.
Ich habe dies auf Gentoos cp ausgeführt, das Coreutils 8.28 ist, um die Dateien zu erhalten, die zum Erstellen cp verwendet wurden, und nach einigem Befehlszeilen-Foo habe ich diese vorläufig als die Patches identifiziert, die für cp relevant sind CentOS:
./coreutils-selinux.patch:diff -urNp coreutils-8.21-orig/src/copy.c coreutils-8.21/src/copy.c
./coreutils-selinux.patch:diff -urNp coreutils-8.21-orig/src/cp.c coreutils-8.21/src/cp.c
./coreutils-8.22-selinux-optionsseparate.patch:diff -urNp coreutils-8.22-orig/src/cp.c coreutils-8.22/src/cp.c
./coreutils-8.22-mv-hardlinksrace.patch:diff -urNp coreutils-8.22-orig/src/copy.c coreutils-8.22/src/copy.c
./coreutils-8.22-cp-sparsecorrupt.patch:diff --git a/src/copy.c b/src/copy.c
./coreutils-8.22-cp-selinux.patch:diff --git a/src/selinux.c b/src/selinux.c
Die berührten Dateien sind enthalten.
Leider könnten sich die zwischen Coreutils-Versionen verwendeten Dateien geändert haben, daher muss ich diese Analyse für die Ausgabe eines Systems mit CentOS 6 oder CentOS 7 erneut ausführen, um eine echte Liste zu erhalten. Ich plane, diese Patches auf Gentoo zu überprüfen / zu testen, um zu sehen, ob ich das Problem von der Seite des Benutzerbereichs aus verfolgen kann. Genug Leute untersuchen die Kernel-Seite, dass ich das angehen werde, bis ich herausgefunden habe, was cp CentOS so besonders macht.
ryao
am 9. Apr. 2018
Ich könnte eine CentOS 7.4-VM einrichten, aber das könnte eine Stunde dauern. Lassen Sie mich wissen, ob ich weitermachen soll oder ob jemand anderes ein System zum Testen bereit hat.
UweSauter
am 9. Apr. 2018
Am 09.04.2018 um 14:05 Uhr schrieb Richard Yao:
Würde jemand mit einem System der CentOS-Familie bitte gdb installieren und
coreutils-debuginfo. Führen Sie dann gdb -ex 'info sources' $(what cp) aus und
die Ausgabe für mich posten? Es wird mir einige Mühe ersparen, meine zu bekommen
ein System in die Hand nehmen, damit ich versuchen kann, herauszufinden, was anders ist
zwischen cp von CentOS und cp von Gentoo.Ich habe dies auf Gentoos cp ausgeführt, das Coreutils 8.28 ist, um die Dateien zu erhalten
die zum Erstellen von cp verwendet wurden, und nach einigem Befehlszeilen-Foo habe ich
identifizierte diese vorläufig als die Patches, die für cp auf CentOS relevant sind:./coreutils-selinux.patch
./coreutils-8.22-selinux-optionsseparate.patch
./coreutils-8.22-non-defaulttests.patch
./coreutils-8.22-mv-hardlinksrace.patch
./coreutils-8.22-failingtests.patch
./coreutils-8.22-cp-sparsecorrupt.patch
./coreutils-8.22-cp-selinux.patchLeider könnten die zwischen Coreutils-Versionen verwendeten Dateien
geändert, daher muss ich diese Analyse für die Ausgabe eines Systems erneut ausführen
Verwenden Sie CentOS 6 oder CentOS 7, um eine echte Liste zu erhalten. Ich plane eine Überprüfung / einen Test
auf Gentoo diese Patches, um zu sehen, ob ich das Problem anhand der ausfindig machen kann
Seite des Benutzerraums. Genug Leute untersuchen die Kernel-Seite
Ich werde das angehen, bis ich herausgefunden habe, was CentOS ausmacht
cp spezial.
CentOS 7.4:
[ root@nas ~]# gdb --ex 'info sources' /usr/bin/cp
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1
Copyright (C) 2013 Free Software Foundation, Inc.
Lizenz GPLv3+: GNU GPL Version 3 oder höher
http://gnu.org/licenses/gpl.html
Dies ist kostenlose Software: Sie können sie frei ändern und weitergeben.
Soweit gesetzlich zulässig, besteht KEINE GEWÄHRLEISTUNG. Geben Sie „zeigen
Kopieren"
und "Garantie anzeigen" für Details.
Diese GDB wurde als „x86_64-redhat-linux-gnu“ konfiguriert.
Anweisungen zum Melden von Fehlern finden Sie unter:
http://www.gnu.org/software/gdb/bugs/ ...
Lesen von Symbolen aus /usr/bin/cp...Lesen von Symbolen aus
/usr/bin/cp...(keine Debugging-Symbole gefunden)...fertig.
(keine Debugging-Symbole gefunden) ... fertig.
Es wird keine Symboltabelle geladen. Verwenden Sie den Befehl "Datei".
Fehlen separate Debuginfos, verwenden Sie: debuginfo-install
coreutils-8.22-18.el7.x86_64
dswartz
am 9. Apr. 2018
@dswartz Dir fehlt die Debuginfo. Führen Sie debuginfo-install coreutils-8.22-18.el7.x86_64 aus und versuchen Sie es erneut. Die Ausgabe sollte in etwa so aussehen:
ryao
am 9. Apr. 2018
Ignorieren Sie mein letztes: falsches Paket ...
dswartz
am 9. Apr. 2018
Quelldateien, für die Symbole eingelesen wurden:
Quelldateien, für die Symbole bei Bedarf eingelesen werden:
/usr/src/debug/coreutils-8.22/src/cp.c, /usr/include/sys/stat.h,
/usr/include/bits/string3.h, /usr/include/bits/stdio2.h,
/usr/src/debug/coreutils-8.22/src/system.h,
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/stddef.h,
/usr/include/bits/types.h,
/usr/include/stdio.h, /usr/include/libio.h, /usr/include/sys/types.h,
/usr/include/time.h, /usr/include/getopt.h,
/usr/include/selinux/selinux.h, /usr/include/bits/stat.h,
/usr/src/debug/coreutils-8.22/lib/argmatch.h,
/usr/src/debug/coreutils-8.22/lib/hash.h,
/usr/src/debug/coreutils-8.22/lib/backupfile.h,
/usr/src/debug/coreutils-8.22/src/copy.h,
/usr/src/debug/coreutils-8.22/lib/stat-time.h,
/usr/src/debug/coreutils-8.22/src/version.h,
/usr/src/debug/coreutils-8.22/lib/exitfail.h,
/usr/src/debug/coreutils-8.22/lib/progname.h,
/usr/src/debug/coreutils-8.22/
/usr/src/debug/coreutils-8.22/lib/xalloc.h,
/usr/src/debug/coreutils-8.22/lib/quote.h, /usr/include/libintl.h,
/usr/include/stdlib.h, /usr/src/debug/coreutils-8.22/lib/error.h,
/usr/include/string.h, /usr/include/bits/errno.h,
/usr/src/debug/coreutils-8.22/lib/dirname.h,
/usr/src/debug/coreutils-8.22/lib/utimens.h, /usr/include/unistd.h,
/usr/src/debug/coreutils-8.22/lib/acl.h, /usr/include/locale.h,
/usr/src/debug/coreutils-8.22/lib/filenamecat.h,
/usr/src/debug/coreutils-8.22/lib/propername.h,
/usr/src/debug/coreutils-8.22/lib/version-etc.h,
/usr/src/debug/coreutils-8.22/src/cp-hash.h,
/usr/src/debug/coreutils-8.22/src/copy.c, /usr/include/bits/unistd.h,
/usr/include/bits/stdio.h,
/usr/src/debug/coreutils-8.22/src/ioblksize.h,
/usr/src/debug/coreutils-8.22/src/extent-scan.h,
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/stdarg.h,
/usr/include/stdint.h, /usr/src/debug/coreutils-8.22/lib/fadvise.h,
/usr/src/debug/coreutils-8.22/lib/utimecmp.h,
/usr/include/attr/error_context.h,
/usr/src/debug/coreutils-8.22/src/selinux.h,
/usr/src/debug/coreutils-8.22/lib/write-any-file.h,
/usr/src/debug/coreutils-8.22/lib/full-write.h,
/usr/include/attr/libattr.h,
/usr/src/debug/coreutils-8.22/lib/verror.h,
/usr/src/debug/coreutils-8.22/lib/unistd.h,
/usr/src/debug/coreutils-8.22/lib/filemode.h,
/usr/src/debug/coreutils-8.22/lib/same.h,
/usr/src/debug/coreutils-8.22/lib/yesno.h,
/usr/src/debug/coreutils-8.22/lib/file-set.h,
/usr/src/debug/coreutils-8.22/lib/areadlink.h,
/usr/src/debug/coreutils-8.22/lib/savedir.h,
/usr/src/debug/coreutils-8.22/lib/fcntl-safer.h,
/usr/src/debug/coreutils-8.22/lib/buffer-lcm.h,
/usr/include/sys/ioctl.h, /usr/include/assert.h,
/usr/src/debug/coreutils-8.22/src/cp-hash.c,
/usr/src/debug/coreutils-8.22/src/extent-scan.c,
/usr/src/debug/coreutils-8.22/src/fiemap.h,
/usr/src/debug/coreutils-8.22/src/selinux.c, /usr/include/bits/fcntl2.h,
/usr/include/selinux/context.h,
/usr/src/debug/coreutils-8.22/lib/canonicalize.h,
/usr/src/debug/coreutils-8.22/lib/i-ring.h,
/usr/src/debug/coreutils-8.22/lib/fts_.h, /usr/include/dirent.h,
/usr/src/debug/coreutils-8.22/lib/xfts.h,
/usr/src/debug/coreutils-8.22/src/version.c,
/usr/src/debug/coreutils-8.22/lib/copy-acl.c,
/usr/src/debug/coreutils-8.22/lib/set-acl.c,
/usr/src/debug/coreutils-8.22/lib/areadlink-with-size.c,
/usr/src/debug/coreutils-8.22/lib/argmatch.c,
/usr/src/debug/coreutils-8.22/lib/quotearg.h,
/usr/src/debug/coreutils-8.22/lib/backupfile.c,
/usr/include/bits/dirent.h,
/usr/src/debug/coreutils-8.22/lib/dirent-safer.h,
/usr/include/bits/confname.h,
/usr/src/debug/coreutils-8.22/lib/buffer-lcm.c,
/usr/src/debug/coreutils-8.22/lib/canonicalize.c,
/usr/include/bits/string2.h,
/usr/src/debug/coreutils-8.22/lib/xgetcwd.h,
/usr/src/debug/coreutils-8.22/lib/closein.c,
/usr/src/debug/coreutils-8.22/lib/freadahead.h,
/usr/src/debug/coreutils-8.22/lib/close-stream.h,
/usr/src/debug/coreutils-8.22/lib/stdio.h,
/usr/src/debug/coreutils-8.22/lib/closeout.h,
/usr/src/debug/coreutils-8.22/lib/closeout.c,
/usr/src/debug/coreutils-8.22/lib/opendir-safer.c,
/usr/src/debug/coreutils-8.22/lib/unistd-safer.h,
/usr/src/debug/coreutils-8.22/lib/dirname.c,
/usr/src/debug/coreutils-8.22/lib/dirname-lgpl.c,
/usr/src/debug/coreutils-8.22/lib/basename-lgpl.c,
/usr/src/debug/coreutils-8.22/lib/stripslash.c,
/usr/src/debug/coreutils-8.22/lib/exitfail.c,
/usr/src/debug/coreutils-8.22/lib/fadvise.c, /usr/include/fcntl.h,
/usr/src/debug/coreutils-8.22/lib/open-safer.c,
/usr/src/debug/coreutils-8.22/lib/file-set.c,
/usr/src/debug/coreutils-8.22/lib/hash-triple.h,
/usr/src/debug/coreutils-8.22/lib/filemode.c,
/usr/src/debug/coreutils-8.22/lib/filenamecat.c,
/usr/src/debug/coreutils-8.22/lib/filenamecat-lgpl.c,
/usr/src/debug/coreutils-8.22/lib/full-write.c,
/usr/src/debug/coreutils-8.22/lib/safe-write.h,
/usr/src/debug/coreutils-8.22/lib/hash.c,
/usr/src/debug/coreutils-8.22/lib/bitrotate.h,
/usr/src/debug/coreutils-8.22/lib/hash-triple.c,
/usr/src/debug/coreutils-8.22/lib/hash-pjw.h,
/usr/src/debug/coreutils-8.22/lib/progname.c, /usr/include/errno.h,
/usr/src/debug/coreutils-8.22/lib/propername.c,
/usr/src/debug/coreutils-8.22/lib/mbuiter.h,
/usr/src/debug/coreutils-8.22/lib/mbchar.h, /usr/include/wchar.h,
/usr/src/debug/coreutils-8.22/lib/strnlen1.h,
/usr/include/wctype.h, /usr/include/ctype.h,
/usr/src/debug/coreutils-8.22/lib/string.h,
/usr/src/debug/coreutils-8.22/lib/trim.h,
/usr/src/debug/coreutils-8.22/lib/xstriconv.h,
/usr/src/debug/coreutils-8.22/lib/localcharset.h,
/usr/src/debug/coreutils-8.22/lib/c-strcase.h,
/usr/src/debug/coreutils-8.22/lib/qcopy-acl.c, /usr/include/sys/acl.h,
/usr/src/debug/coreutils-8.22/lib/acl-internal.h,
/usr/src/debug/coreutils-8.22/lib/qset-acl.c, /usr/include/acl/libacl.h,
/usr/src/debug/coreutils-8.22/lib/quotearg.c,
/usr/src/debug/coreutils-8.22/lib/c-strcaseeq.h,
/usr/src/debug/coreutils-8.22/lib/safe-read.c,
/usr/src/debug/coreutils-8.22/lib/same.c,
/usr/src/debug/coreutils-8.22/lib/savedir.c,
/usr/src/debug/coreutils-8.22/lib/strnlen1.c,
/usr/src/debug/coreutils-8.22/lib/trim.c,
/usr/src/debug/coreutils-8.22/lib/mbiter.h,
/usr/src/debug/coreutils-8.22/lib/dup-safer.c,
/usr/src/debug/coreutils-8.22/lib/fcntl.h,
/usr/src/debug/coreutils-8.22/lib/fd-safer.c,
/usr/src/debug/coreutils-8.22/lib/utimecmp.c,
/usr/src/debug/coreutils-8.22/lib/utimens.c, /usr/include/bits/time.h,
/usr/src/debug/coreutils-8.22/lib/timespec.h,
/usr/src/debug/coreutils-8.22/lib/sys/stat.h, /usr/include/sys/time.h,
/usr/src/debug/coreutils-8.22/lib/verror.c,
/usr/src/debug/coreutils-8.22/lib/xvasprintf.h,
/usr/src/debug/coreutils-8.22/lib/version-etc.c,
/usr/src/debug/coreutils-8.22/lib/version-etc-fsf.c,
/usr/src/debug/coreutils-8.22/lib/write-any-file.c,
/usr/src/debug/coreutils-8.22/lib/xmalloc.c,
/usr/src/debug/coreutils-8.22/lib/xalloc-die.c,
/usr/src/debug/coreutils-8.22/lib/xfts.c,
/usr/src/debug/coreutils-8.22/lib/xgetcwd.c,
/usr/src/debug/coreutils-8.22/lib/xstriconv.c, /usr/include/iconv.h,
/usr/src/debug/coreutils-8.22/lib/striconv.h,
/usr/src/debug/coreutils-8.22/lib/xvasprintf.c,
/usr/src/debug/coreutils-8.22/lib/xsize.h,
/usr/src/debug/coreutils-8.22/lib/yesno.c,
/usr/src/debug/coreutils-8.22/lib/fcntl.c,
/usr/src/debug/coreutils-8.22/lib/fflush.c,
/usr/include/stdio_ext.h,
/usr/src/debug/coreutils-8.22/lib/freadahead.c,
/usr/src/debug/coreutils-8.22/lib/fseeko.c,
/usr/src/debug/coreutils-8.22/lib/fts-cycle.c,
/usr/src/debug/coreutils-8.22/lib/fts.c,
/usr/src/debug/coreutils-8.22/lib/cycle-check.h,
/usr/src/debug/coreutils-8.22/lib/dev-ino.h, /usr/include/bits/statfs.h,
/usr/src/debug/coreutils-8.22/lib/cloexec.h, /usr/include/sys/statfs.h,
/usr/src/debug/coreutils-8.22/lib/getfilecon.c,
/usr/src/debug/coreutils-8.22/lib/linkat.c,
/usr/src/debug/coreutils-8.22/lib/at-func.c,
/usr/src/debug/coreutils-8.22/lib/utimensat.c,
/usr/src/debug/coreutils-8.22/lib/save-cwd.h,
/usr/src/debug/coreutils-8.22/lib/openat-priv.h,
/usr/src/debug/coreutils-8.22/lib/openat.h,
/usr/src/debug/coreutils-8.22/lib/vasprintf.c,
/usr/src/debug/coreutils-8.22/lib/vasnprintf.h,
/usr/src/debug/coreutils-8.22/lib/areadlinkat.c,
/usr/src/debug/coreutils-8.22/lib/caredlinkat.h,
/usr/src/debug/coreutils-8.22/lib/c-strcasecmp.c,
/usr/src/debug/coreutils-8.22/lib/careadlinkat.c,
/usr/src/debug/coreutils-8.22/lib/allocator.h,
/usr/src/debug/coreutils-8.22/lib/cloexec.c,
/usr/src/debug/coreutils-8.22/lib/close-stream.c,
/usr/src/debug/coreutils-8.22/lib/cycle-check.c,
/usr/src/debug/coreutils-8.22/lib/gettime.c,
/usr/src/debug/coreutils-8.22/lib/hash-pjw.c,
/usr/src/debug/coreutils-8.22/lib/i-ring.c,
/usr/src/debug/coreutils-8.22/lib/localcharset.c,
/usr/include/nl_types.h,
/usr/include/langinfo.h, /usr/src/debug/coreutils-8.22/lib/mbchar.c,
/usr/src/debug/coreutils-8.22/lib/str-kmp.h,
/usr/src/debug/coreutils-8.22/lib/mbsstr.c,
/usr/src/debug/coreutils-8.22/lib/malloca.h,
/usr/src/debug/coreutils-8.22/lib/openat-die.c,
/usr/src/debug/coreutils-8.22/lib/openat-safer.c,
/usr/src/debug/coreutils-8.22/lib/acl-errno-valid.c,
/usr/src/debug/coreutils-8.22/lib/file-has-acl.c,
/usr/src/debug/coreutils-8.22/lib/save-cwd.c,
/usr/src/debug/coreutils-8.22/lib/chdir-long.h,
/usr/src/debug/coreutils-8.22/lib/striconv.c,
/usr/src/debug/coreutils-8.22/lib/chdir-long.c,
/usr/src/debug/coreutils-8.22/lib/fclose.c,
/usr/src/debug/coreutils-8.22/lib/openat-proc.c,
/usr/src/debug/coreutils-8.22/lib/vasnprintf.c,
/usr/src/debug/coreutils-8.22/lib/printf-args.h,
/usr/src/debug/coreutils-8.22/lib/printf-parse.h,
/usr/src/debug/coreutils-8.22/lib/fpucw.h,
/usr/src/debug/coreutils-8.22/lib/isnanl-nolibm.h,
/usr/src/debug/coreutils-8.22/lib/allocator.c,
/usr/src/debug/coreutils-8.22/lib/malloca.c,
/usr/src/debug/coreutils-8.22/lib/mbslen.c,
/usr/src/debug/coreutils-8.22/lib/isnan.c,
/usr/src/debug/coreutils-8.22/lib/printf-args.c,
/usr/src/debug/coreutils-8.22/lib/printf-parse.c
dswartz
am 9. Apr. 2018
@dswartz Würden Sie Ihren Beitrag bearbeiten, um ein Pastebin zu verwenden? Außerdem, warum gibt es nichts unter Source files for which symbols have been read in: ? Hast du die Ausgabe bearbeitet?
ryao
am 9. Apr. 2018
Am 09.04.2018 um 14:17 Uhr schrieb Richard Yao:
@dswartz [1] Würden Sie Ihren Beitrag bearbeiten, um ein Pastebin zu verwenden?
Sicher.
dswartz
am 9. Apr. 2018
Die Patches, die für cp gelten, soweit gdb behauptet, dass seine Quelldateien sind (mit Patches, die nur Testfälle bearbeiten, die nicht auf die cp-Binärdatei zutreffen, entfernt) sind die gleichen, die ich nach der Verarbeitung der gdb-Ausgabe von Gentoos cp erhalten habe, was ist :
./coreutils-selinux.patch:diff -urNp coreutils-8.21-orig/src/copy.c coreutils-8.21/src/copy.c
./coreutils-selinux.patch:diff -urNp coreutils-8.21-orig/src/cp.c coreutils-8.21/src/cp.c
./coreutils-8.22-selinux-optionsseparate.patch:diff -urNp coreutils-8.22-orig/src/cp.c coreutils-8.22/src/cp.c
./coreutils-8.22-mv-hardlinksrace.patch:diff -urNp coreutils-8.22-orig/src/copy.c coreutils-8.22/src/copy.c
./coreutils-8.22-cp-sparsecorrupt.patch:diff --git a/src/copy.c b/src/copy.c
./coreutils-8.22-cp-selinux.patch:diff --git a/src/selinux.c b/src/selinux.c
Die Änderungen in ./coreutils-8.22-mv-hardlinksrace.patch erscheinen mir fragwürdig, aber ich sehe keinen rauchenden Colt. Das Testen auf Gentoo nach dem Anwenden dieser Patches sollte es uns ermöglichen, herauszufinden, welcher es auf CentOS reproduzierbar macht.
ryao
am 9. Apr. 2018
Am 09.04.2018 um 14:17 Uhr schrieb Richard Yao:
@dswartz [1] Würden Sie Ihren Beitrag bearbeiten, um ein Pastebin zu verwenden?
dswartz
am 9. Apr. 2018
Reproduzierbarkeit: nein
Distributionsname und Version: Fedora 27
Kernel-Version: 4.15.10-300.fc27.x86_64
Coreutils-Version: 8.27-20.fc27
SELinux-Status: aus
BEARBEITEN: Der CP dieser Maschine kopiert in alphanumerischer Reihenfolge (überprüft mit strace).
Ringdingcoder
am 9. Apr. 2018
Nicht reproduzierbar mit dem archzfs-Repo von Arch Linux (danke, @demizer).
■ mkdir SRC
■ for i in $(seq 1 10000); do echo $i > SRC/$i ; done
■ cp -r SRC DST
■ uname -srvmo
Linux 4.15.15-1-ARCH #1 SMP PREEMPT Sat Mar 31 23:59:25 UTC 2018 x86_64 GNU/Linux
■ LC_ALL=C pacman -Qi coreutils spl-linux spl-utils-common zfs-linux zfs-utils-common | grep '^Version '
Version : 8.29-1
Version : 0.7.7.4.15.15.1-1
Version : 0.7.7-1
Version : 0.7.7.4.15.15.1-1
Version : 0.7.7-1
■ zpool get all | sed '2,$s/^..../tank/g'
NAME PROPERTY VALUE SOURCE
tank size 43.5T -
tank capacity 81% -
tank altroot - default
tank health ONLINE -
tank guid xxxxxxxxxxxxxxxxxxx -
tank version - default
tank bootfs - default
tank delegation on default
tank autoreplace off default
tank cachefile - default
tank failmode wait default
tank listsnapshots off default
tank autoexpand off default
tank dedupditto 0 default
tank dedupratio 1.00x -
tank free 8.00T -
tank allocated 35.5T -
tank readonly off -
tank ashift 12 local
tank comment - default
tank expandsize - -
tank freeing 0 -
tank fragmentation 34% -
tank leaked 0 -
tank multihost off default
tank feature<strong i="6">@async_destroy</strong> enabled local
tank feature<strong i="7">@empty_bpobj</strong> active local
tank feature<strong i="8">@lz4_compress</strong> active local
tank feature<strong i="9">@multi_vdev_crash_dump</strong> disabled local
tank feature<strong i="10">@spacemap_histogram</strong> active local
tank feature<strong i="11">@enabled_txg</strong> active local
tank feature<strong i="12">@hole_birth</strong> active local
tank feature<strong i="13">@extensible_dataset</strong> enabled local
tank feature<strong i="14">@embedded_data</strong> active local
tank feature<strong i="15">@bookmarks</strong> enabled local
tank feature<strong i="16">@filesystem_limits</strong> enabled local
tank feature<strong i="17">@large_blocks</strong> enabled local
tank feature<strong i="18">@large_dnode</strong> disabled local
tank feature<strong i="19">@sha512</strong> disabled local
tank feature<strong i="20">@skein</strong> disabled local
tank feature<strong i="21">@edonr</strong> disabled local
tank feature<strong i="22">@userobj_accounting</strong> disabled local
NoSuck
am 9. Apr. 2018
Die Version 0.7.7 wurde aus den CentOS- und Fedora-RPM-Repositories entfernt.
behlendorf
am 9. Apr. 2018
@rincebrain bestätigte, dass dies mit touch reproduzierbar ist, um die Datei in der richtigen Reihenfolge zu erstellen (um den Zap mit Hash-Kollisionen aufzublasen). Ich werde einen minimalen Testfall posten.
trisk
am 9. Apr. 2018
@trisk Vielleicht möchten Sie sich zuerst den Testfall in https://github.com/zfsonlinux/zfs/pull/7411 ansehen
tonyhutter
am 9. Apr. 2018
Diese haben die Sortierung geändert:
http://git.savannah.gnu.org/cgit/coreutils.git/commit/src?id=069723c5eef34736b35b21af1d76ddfbd594a259 oder
http://git.savannah.gnu.org/cgit/coreutils.git/commit/src?id=7bbfd1735574be80971b597b34f779fe6938a595
Ringdingcoder
am 9. Apr. 2018
@Ringdingcoder Schöner Fund. Das könnte die Dinge gut erklären, wenn einige Tests mit/ohne das bestätigen, dass es der Unterschied ist.
ryao
am 9. Apr. 2018
@Ringdingcoder Ich habe dies gerade in einer alten Gentoo-VM reproduziert, die Coreutils 8.21 verwendet. Es ist betroffen. Dort sind keine Redhat-Patches vorhanden. Ich werde versuchen, mit den Patches zu reproduzieren, die Sie verlinkt haben, und sehen, was passiert. Ich erwarte, dass einer von ihnen das Problem verschwinden lässt.
ryao
am 9. Apr. 2018
Sie benötigen dies:
```--- a/src/copy.c
+++ b/src/copy.c
@@ -717,7 +717,7 @@ copy_dir (char const *src_name_in, char const *dst_name_in, bool new_dst,
struct cp_options non_command_line_options = *x;
bool ok = wahr;
- name_space = savedir (src_name_in, SAVEDIR_SORT_FASTREAD);
- name_space = savedir (src_name_in, SAVEDIR_SORT_NONE);
if (name_space == NULL)
{
/* Diese Diagnose ist etwas vage, da savedir fehlschlagen kann
```
Ringdingcoder
am 9. Apr. 2018
Shell-Skript zum Reproduzieren (cp nicht erforderlich): https://gist.github.com/trisk/9966159914d9d5cd5772e44885112d30
trisk
am 9. Apr. 2018
Nein, eigentlich gehst du in die andere Richtung. Dann bräuchte man Patch gnulib. Einfachere Rückkehr zu unsortiert von einer neueren Version.
Ringdingcoder
am 9. Apr. 2018
@Ringdingcoder Ich habe gerade festgestellt, dass lib/savedir.c nicht in den Quelldateien existiert, die ich habe. Ich habe eine alte VM ausgewählt, die zufällig 8.21 hatte. Ich werde es auf 8.23 aktualisieren und dann zurückkehren, um die Dinge zu überprüfen.
ryao
am 9. Apr. 2018
Ich kann es sofort reproduzieren, indem ich mit SAVEDIR_SORT_NONE gehe. Dies erklärt, warum nur alte Distributionen dies erleben. IIRC, tar ist unsortiert, also sollte ein "tar cf - SRC | tar -C DST -xf -" dies überall auslösen können (ungetestet).
Offensichtlich tut dies auch die fest codierte Sequenz aus dem Skript von Trisk.
Ringdingcoder
am 9. Apr. 2018
Mit dem Skript von @trisk kann ich dies sofort auf 64-Bit-Ubuntu 16.04 (Kernel 4.4.0-109-generic) mit ZFS 0.7.7 reproduzieren. Es schlägt wie erwartet fehl:
touch: cannot touch 'DST/9259': No space left on device
siebenmann
am 9. Apr. 2018
@ryao Ja, die eigentliche Codeänderung ist diese: http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=be7d73709d2b3bceb987f1be00a049bb7021bf87
Ringdingcoder
am 9. Apr. 2018
@Ringdingcoder Ich denke, wir haben zufriedenstellend erklärt, was sich zwischen verschiedenen Distributionen unterscheidet, dass nur die RHEL-Distributionen betroffen sind. Ich werde dazu übergehen, zu verstehen, was im Kernel schief läuft.
Ich habe ein Problem mit der Beschädigung der Linkanzahl beobachtet, das zwischen umounts bestand, als ich dies reproduziert habe, aber ich hatte Probleme, das Problem zuverlässig zu reproduzieren, sodass ich einen Reproduzierer für das Problem mit der Linkanzahl habe.
ryao
am 9. Apr. 2018
Ich habe den Fehler jetzt auf Arch Linux reproduziert, indem ich eine korrigierte Version des Skripts von @trisk verwendet habe (unexpected token error, line 6). Ich kann den Fehler nicht konsistent reproduzieren:
■ export LC_ALL=C
■ rm -r DST
■ ./zap-collision-test.sh
■ rm -r DST
■ ./zap-collision-test.sh
touch: cannot touch 'DST/9259': No space left on device
■ rm -r DST
■ ./zap-collision-test.sh
touch: cannot touch 'DST/9259': No space left on device
■ rm -r DST
■ ./zap-collision-test.sh
■ rm -r DST
■ ./zap-collision-test.sh
touch: cannot touch 'DST/9259': No space left on device
■ rm -r DST
■ ./zap-collision-test.sh
■
@NoSuck Kann mit dem Skript von @trisk auch auf Arch bestätigen. Damit entkräftet sich mein vorheriger Kommentar.
local/spl-linux-git 2018.04.04.r1070.581bc01.4.15.15.1-1 (archzfs-linux-git)
local/spl-utils-common-git 2018.04.04.r1070.581bc01-1 (archzfs-linux-git)
local/zfs-linux-git 2018.04.04.r3402.533ea0415.4.15.15.1-1 (archzfs-linux-git)
local/zfs-utils-common-git 2018.04.04.r3402.533ea0415-1 (archzfs-linux-git)
Mit dem Skript von @trisk (gut, eine leicht korrigierte Version) kann ich dies auf einer fast aktuellen Version des Git-Tipps g1724eb62d auf Fedora 27 auf einem einfachen gespiegelten vdev in einer VM reproduzieren. Es passiert nicht bei jedem Lauf, aber es passiert ziemlich häufig (mindestens die Hälfte der Zeit, glaube ich).
(Diese Git-Version ist die neueste Version, die ich für meinen eigenen Gebrauch gebaut habe. Ich kann mit dem allerneuesten Git-Tipp testen, aber ich sehe dort nichts, was dies ändern würde, wenn die identifizierte Ursache richtig ist. Ich' d gerne Updates in der VM testen.)
siebenmann
am 9. Apr. 2018
Es könnte von Bedeutung sein, dass wir bei 2048 Dateien das Zap-Expansionslimit erreicht haben (ob dies jedoch eine Eigenschaft der Coreutils-Sortierung oder der Zap-Hash-Funktion widerspiegelt, ist unklar).
trisk
am 9. Apr. 2018
Der ursprüngliche Reproduzierer erstellt verwaiste Dateien, wenn er ausgelöst wird, während der Reproduzierer von @trisk dies nicht tut. Nach dem Ausführen des ursprünglichen Reproprogramms habe ich einen Fehler bei 1 Datei, 8186 Dateien im Verzeichnis gemäß ls -l DST | wc und einer Verzeichnisgröße von 10001 festgestellt. Die Verknüpfung aller Dateien wurde aufgehoben, während versucht wurde, sie zu statisieren, um zu sehen, ob auf sie zugegriffen werden konnte trotz einer Verzeichnisgröße von 1816 fehlgeschlagen. Hier ist die zdb-Ausgabe aus einem Testpool, mit dem ich das Problem reproduziert habe:
https://bpaste.net/show/d9f2f0de6c61
Ich habe vergessen, wie oft ich den Repro-Player darauf ausgeführt habe (wahrscheinlich zweimal), aber die verwaisten Dateien sind deutlich sichtbar. Hier ist ein komprimiertes Bild des Pools:
https://dev.gentoo.org/~ryao/7401-pool-orphaned-files.xz
Es hat sha256 5bf54d804f0cd6cd155cc781efeefdabaa6e0ddddc500695eb24061d802474ac. Der Pool selbst ist nur eine 1 GB große Sparse-Datei. Die komprimierte Version ist 1938032 Bytes (~2 MB) groß. Andere können zdb darauf verwenden und herumstöbern, um die verwaisten Dateien zu beobachten.
ryao
am 9. Apr. 2018
Ich trete wegen eines Termins, den ich nicht vorwegnehmen kann, für eine Weile aus, aber ich möchte nur darauf hinweisen, dass diejenigen, die Dateien verloren haben, sie möglicherweise noch als Waisenkinder haben. Wir müssen einen Pool untersuchen, in dem dies mit Dateien passiert ist, in denen tatsächliche Daten gespeichert sind, um zu bestätigen, dass die Daten vorhanden sind. Wenn dies der Fall ist, können die Daten möglicherweise wiederhergestellt werden.
ryao
am 9. Apr. 2018
Vielen Dank an alle für Ihre Hilfe bei dieser unglücklichen Regression. Wie oben von @tuxoko beschrieben, ist die Ursache dieses Problems bekannt und es wird derzeit an einer vollständigen Lösung gearbeitet. In der Zwischenzeit wird der Commit cc63068e95ee725cce03b1b7ce50179825a6cda5, der dieses Problem eingeführt hat, in Kürze aus dem Master-Zweig zurückgesetzt, der Release-Zweig und v0.7.8 wird getaggt. Wir öffnen eine neue PR mit dem vollständigen Fix zur Überprüfung und für Feedback, sobald er fertig ist.
behlendorf
am 9. Apr. 2018
@behlendorf Da sind noch einige lose Enden. Wie gehen wir insbesondere mit den Betroffenen um? Es könnten verwaiste Dateien in ihren Datensätzen vorhanden sein.
Derzeit könnten wir den Leuten sagen, dass sie Änderungen zwischen dem, was sie jetzt haben, und dem Snapshot sichern, bevor das Problem auftrat, ein Rollback durchführen und dann wiederherstellen, vorausgesetzt, sie haben überhaupt Snapshots. Wenn nicht, wäre die Lösung im Moment, einen neuen Datensatz zu erstellen, die Dateien dorthin zu kopieren und dann den alten zu zerstören.
Beides ist keine so saubere Lösung, wie etwas wie zfs lost+found -r tank zu tun und die verwaisten Dateien in verlorene+gefundene Verzeichnisse zu legen. Es wird noch chaotischer, wenn wir bedenken, dass verwaiste Dateien in kürzlich erstellten Snapshots enthalten sein könnten.
Dass dies auf Systemen außerhalb der RHEL-Familie schwer zu reproduzieren war, war ein loses Ende, aber es war nur gebunden. Die Änderung in der gebündelten Gnulib zwischen den Coreutils 8.22 und 8.23 änderte die Reihenfolge, in der die Dinge kopiert wurden, von einer sequentiellen zu einer pseudozufälligen Reihenfolge.
Schließlich hatten wir etwa ein Dutzend Leute auf der ganzen Welt, die alles hinschmissen, um daran zu arbeiten. Wir sind noch nicht alle auf derselben Seite und es wird einige Zeit dauern, bis wir unser Verständnis synchronisiert haben. Auf diese Weise können wir alle die endgültige Lösung überprüfen.
ryao
am 9. Apr. 2018
Ich sollte hinzufügen, dass wir auch eine Möglichkeit brauchen, um nach Waisenkindern zu suchen. Ich habe bestätigt, dass zdb es anzeigen kann, aber ich habe noch nicht bestimmt, was zdb in allen Fällen (hauptsächlich Nicht-Null-Dateien) anzeigen würde, um eine zuverlässige Erkennung zu ermöglichen.
ryao
am 9. Apr. 2018
Unsere Analyse hat bisher nicht festgestellt, wie die zusätzlichen Dateien, deren zap_add nach einem vorherigen Zap-Expansion-Fehler im Verzeichnis abgeschlossen wird, verwaisen.
trisk
am 9. Apr. 2018
Unsere Analyse ist noch nicht abgeschlossen. Ich eröffne dies erneut, bis unsere Analyse abgeschlossen ist.
ryao
am 9. Apr. 2018
Richtig, ich wollte nicht vorschlagen, dass dieses Problem geschlossen werden sollte, und es war alles, was nötig war, die Änderung rückgängig zu machen. Es müssen noch eindeutig sorgfältige Untersuchungen durchgeführt werden, auf die wir uns jetzt konzentrieren können.
@ryao Wenn möglich, wäre ein Zurücksetzen auf einen Snapshot der sauberste Weg, um diese Dateien wiederherzustellen. Da dies jedoch nicht immer eine Option sein wird, untersuchen wir die Implementierung eines generischen Orhpan-Wiederherstellungsmechanismus. Das anfängliche Hinzufügen dieser Funktionalität zu zdb würde es uns ermöglichen, vorhandene Datensätze zu überprüfen, und wäre eine schöne zusätzliche Testabdeckung, die ztest nutzen kann. Wir könnten dies möglicherweise mit Unterstützung für ein .zfs/lost+found -Verzeichnis weiterverfolgen.
behlendorf
am 9. Apr. 2018
Kann angesichts des verbesserten Verständnisses der Ursache dieser Regression etwas über das Verhalten von rsync gesagt werden? Wenn keine Fehler gemeldet werden, sind die Daten in Ordnung?
Was ist mit mv? Und was ist, wenn mv von einem Datensatz zum anderen im selben Pool ist?
darrenfreeman
am 10. Apr. 2018
@darrenfreeman Die Mailingliste oder der IRC-Chatroom wären wahrscheinlich ein besserer Ort, um zu fragen, aber
- rsync sollte in Ordnung sein, da _ich denke_ es auf zB rsync -a src/ dst/ aussteigen sollte, sobald es einmal ENOSPC erhält, und keine zusätzlichen Dateien ausprobieren
- mv über Datensätze in einem Pool hinweg ist genau wie mv über andere Dateisysteme, cp dann rm, also würde ich vermuten, dass dies den gleichen Vorbehalten bezüglich der Versionseigenheiten unterliegt wie cp oben, aber ich habe das nicht getestet.
Außerdem eine letzte Einschränkung:
- Das Wissen, insbesondere darüber, wie viele Schwachstellen für Dateien vorhanden sind, die in der metaphorischen Mischung verloren gehen, nachdem ENOSPC zurückerhalten wurde, ist unvollständig, daher ist es am sichersten, Versionen zurückzusetzen (oder nach 0.7.8 zu kürzen), wenn dies überhaupt möglich ist, und alles darüber ist aufgrund unvollständiger Angaben.
rincebrain
am 10. Apr. 2018
rsync sortiert Dateien immer, also sollte es in Ordnung sein. Und solange Sie keine Fehler erhalten, sollte es Ihnen gut gehen.
Da Daten nicht stillschweigend verloren gehen, ist dies nicht der schlimmste katastrophale Fehler, sondern nur ein großes Ärgernis. Das unangenehmste Problem dabei sind die verwaisten Dateien, aber glücklicherweise sind sie an ihre jeweiligen Datensätze gebunden, nicht an den gesamten Pool, und können durch Zurücksetzen oder Neuerstellen einzelner Datensätze entfernt werden.
Ringdingcoder
am 10. Apr. 2018
Reproduzierbarkeit: ja
ZoL-Version: git, letzter Commit, 10adee27ced279c381816e1321226fce5834340c
Verteilung: Ubuntu 17.10
Kernel-Version: 4.13.0-38-generisch
Coreutils-Version: 8.26-3ubuntu4
SELinux-Status: nicht installiert AFAICT
Reproduziert mit: ./zap-collision-test.sh .
Außerdem sah das nicht gut aus:
rm -Rf DST
Segmentation fault (core dumped)
Der Pool wurde frisch angelegt, da
zfs create rpool/test -o recordsize=4k
touch -s 1G /rpool/test/file
zpool create test /rpool/test/file -o ashift=12
Ich versuche, die Debug-Symbole für rm zu installieren, bekomme aber jetzt auch Segfaults, wenn ich diesen Zpool nicht einmal anfasse. (apt-key ist segfaulting, wenn versucht wird, dem Debug-Repo zu vertrauen.) Ich fürchte, ich drücke jetzt besser die Kommentartaste und starte neu :/
Update: Der Segfault auf rm -Rf DST kann nach dem Neustart und der Installation von Debug-Symbolen nicht reproduziert werden.
darrenfreeman
am 10. Apr. 2018
Vielen Dank für die Lösungen und die schnellen Bemühungen zur Behebung.
Gibt es Methoden, um ein komplettes Dateisystem auf betroffene Dateien zu überprüfen? Ich habe Backups - gibt mir jemand einen Einzeiler, um sie aufzulisten?
ort163
am 10. Apr. 2018
Da dieser Fehler jetzt auf The Register (https://www.theregister.co.uk/2018/04/10/zfs_on_linux_data_loss_fixed/) aufgeführt wurde, könnte es sinnvoll sein, einen FAQ-Artikel auf der Wiki-Seite zu haben (mit einem Link darin diese Fahrkarte). Der FAQ-Artikel sollte klar angeben, welche Versionen von ZoL betroffen sind und welche Distributionen/Kernel-Versionen (ähnlich dem Geburtsloch-Bug). Dies würde hoffentlich alle panischen Bedenken hinsichtlich der Zuverlässigkeit von ZoL als Speicherschicht begrenzen.
markdesouza
am 10. Apr. 2018
Da dieser Fehler nun auf The Register (https://www.theregister.co.uk/2018/04/10/zfs_on_linux_data_loss_fixed/) aufgeführt wurde
Aus diesem Artikel (Hervorhebung von mir):
„Obwohl drei Rezensenten den schäbigen Commit unterschrieben haben , könnte die schnelle Antwort bedeuten, dass es möglich ist, dies als eine Art Triumph für Open Source zu betrachten.“
Autsch.
Ich stimme @markdesouza zu, dass es dafür einen FAQ-Artikel geben sollte, damit wir ZFS-Entschuldiger jeden darauf hinweisen können, der uns dazu befragt. Ich möchte auch vorschlagen, dass das ZFS-Abmeldeverfahren überprüft wird, um zu vermeiden (oder es zumindest viel unwahrscheinlicher zu machen ), dass ein solches "unsauberes Commit" es in eine stabile ZFS-Veröffentlichung schafft, und auch diese Benachrichtigung über diese Überprüfung zu demselben FAQ-Artikel hinzugefügt werden.
durval-menezes
am 10. Apr. 2018
In #7411 sieht der random_creation -Test so aus, als wäre er ein robusterer Reproduzierer (insbesondere für zukünftige Fehler), da er sich natürlich auf die Reihenfolge der ZAP-Hashes verlässt. Auch wenn es andere Vervielfältiger gibt, könnte es eine gute Idee sein, die Diskussion über sie in dieser PR zu zentralisieren, damit sie leicht einbezogen werden können.
aerusso
am 10. Apr. 2018
Beantwortung meiner früheren Frage. Debian 9.3 wie oben.
rsync trifft den Fehler nicht, es erstellt Dateien in lexikalischer Reihenfolge. (D. h. auf die Datei 999 folgt 9990 .) In einer sehr kleinen Anzahl von Tests habe ich keine Kombination von Schaltern gefunden, die fehlschlagen würde.
Wer also rsync bevorzugt, sollte ziemlich gute Chancen haben, den Bug verpasst zu haben.
Etwas Ähnliches wie mv /pool/dataset1/SRC /pool/dataset2/ ist auch nicht fehlgeschlagen. (Wechseln Sie zwischen Datensätzen innerhalb desselben Pools.) Obwohl cp auf derselben Box auch nicht fehlschlägt, beweist das nicht viel.
darrenfreeman
am 10. Apr. 2018
FYI – Sie haben es wahrscheinlich alle schon gesehen, aber wir haben gestern Abend zfs-0.7.8 mit dem rückgängig gemachten Patch veröffentlicht.
tonyhutter
am 10. Apr. 2018
@ort163 Wir haben noch keinen Einzeiler. Die Leute analysieren das Problem weiterhin und wir werden in naher Zukunft eine geeignete Lösung finden. Dazu gehört eine Möglichkeit, die falschen Verzeichnisgrößen zu erkennen und zu korrigieren, betroffene Snapshots aufzulisten und die verwaisten Dateien in einer Art Lost+Found-Verzeichnis abzulegen. Ich neige dazu, das Peeling zu erweitern, um dies zu tun.
ryao
am 10. Apr. 2018
@markdesouza Ich habe ziemlich viel Zeit damit verbracht, Endbenutzern Dinge auf Hacker News, Reddit und Phoronix zu erklären. Ich denke, dass unser Verständnis noch nicht ausreicht, um eine abschließende FAQ zu veröffentlichen, aber wir könnten eine vorläufige FAQ veröffentlichen.
Ich denke, der vorläufige FAQ-Eintrag sollte Benutzern raten, so schnell wie möglich zu aktualisieren, um möglicherweise nicht mit verwaisten Dateien umgehen zu müssen, wenn noch nichts passiert ist, oder mit weiteren verwaisten Dateien, wenn bereits etwas passiert ist. und ihre Vorgehensweise nach dem Upgrade nicht zu ändern, es sei denn, sie halten es für notwendig, bis wir unsere Analyse abgeschlossen, eine ordnungsgemäße Lösung vorgenommen und in den Versionshinweisen ordnungsgemäße Anweisungen zur Behebung des Schadens herausgegeben haben. Ich glaube nicht, dass Pools Schaden nehmen, wenn Datensätze falsche Verzeichnisgrößen und verwaiste Dateien haben, während die Leute darauf warten, dass wir einen richtigen Fix mit Anweisungen zur vollständigen Behebung des Problems veröffentlichen, also sollte es in Ordnung sein, ihnen zu sagen, dass sie nach dem Upgrade warten sollen. Die verwaisten Dateien sollten in der Nähe bleiben und durch Senden/Empfangen bestehen bleiben, es sei denn, es wird ein Snapshot-Rollback durchgeführt oder das Dataset zerstört.
Bis dahin können Sie die Benutzer auf meinen Hacker-News-Beitrag verweisen:
https://news.ycombinator.com/item?id=16797932
Insbesondere müssen wir feststellen, ob die Verzeichniseinträge bestehender Dateien verloren gehen könnten, was, wenn andere Nebenwirkungen auftreten, wenn dies bei der Erstellung neuer Dateien ausgelöst wird, welche Ereignisse dazu führen, dass Verzeichniseinträge nach ENOSPC verschwinden, wie Systemadministratoren dies tun könnten erkennen und wie Systemadministratoren es reparieren. Dann sollten wir in der Lage sein, einen richtigen FAQ-Eintrag zu machen.
Bearbeiten: Die ersten 3 Fragen werden in #7421 zufriedenstellend beantwortet.
ryao
am 10. Apr. 2018
Verwandte Themen
nwf
·
4Kommentare
tronder88
·
3Kommentare
marker5a
·
4Kommentare
Baughn
·
4Kommentare
adamdmoss
·
3Kommentare
Hilfreichster Kommentar
Vielen Dank an alle für Ihre Hilfe bei dieser unglücklichen Regression. Wie oben von @tuxoko beschrieben, ist die Ursache dieses Problems bekannt und es wird derzeit an einer vollständigen Lösung gearbeitet. In der Zwischenzeit wird der Commit cc63068e95ee725cce03b1b7ce50179825a6cda5, der dieses Problem eingeführt hat, in Kürze aus dem Master-Zweig zurückgesetzt, der Release-Zweig und v0.7.8 wird getaggt. Wir öffnen eine neue PR mit dem vollständigen Fix zur Überprüfung und für Feedback, sobald er fertig ist.