Bug #8233
closedzdb fails to read label 2 and label 3 after miscalculating addresses of labels
0%
Description
This seems to have materialized not so long ago, at least I don't remember encountering this problem more than a year ago. What appears to happen is zdb, while it scans labels, given for example a command as follows, reports that it failed to read last two labels.
zdb -lu c2t0d0s0
What zdb reports, given above command.
------------------------------------ LABEL 2 ------------------------------------ failed to read label 2 ------------------------------------ LABEL 3 ------------------------------------ failed to read label 3
This snippet suggests that last two addresses are miscalculated. I am fairly sure they cannot exist, given sizes of disks with which I have been getting these numbers. In fact, I am seeing same values no matter what the size of the actual disk is. This is certainly a problem.
psize: 0x0 l: 0x0 offset: 0x0 return: 0x0 psize: 0x0 l: 0x1 offset: 0x0 return: 0x40000 psize: 0x0 l: 0x2 offset: 0x0 return: 0xfffffffffff80000 psize: 0x0 l: 0x3 offset: 0x0 return: 0xfffffffffffc0000
Problem is likely related to using `stat64` to get information about the disk. At least as far as I can tell, stat is where things go wrong in the dump_label function in zdb.c.
This snippet makes it apparent that addresses for labels 2 and 3 are most certainly bogus.
dtrace -qn 'pid$target:::entry /probefunc=="vdev_label_offset"/ { /* Trace three arguments to vdev_label_offset */ psize = (uint64_t)arg0 ; lbl = arg1 ; off = (uint64_t)arg2 ; } pid$target:::return /probefunc=="vdev_label_offset"/ { printf("psize: 0x%x l: 0x%x offset: 0x%x return: 0x%x\n", psize, lbl, off, arg1); }' -c 'zdb -lu c2t0d0s0'
Related issues
Updated by Yuri Pankov about 5 years ago
- Is duplicate of Bug #8108: zdb -l fails to read labels 2 and 3 added