Bug #7399
openEndianness bugs with "zdb -R"
0%
Description
There are two bugs in "zdb -R"
First, on a little endian machine the hex dump of a native-endian file is shown byte-reversed, although the ASCII dump is ok. This is caused by casting an unsigned char* to a uint64_t* without the required byte swap. To reproduce:
zpool create foo c2t2d0
zfs create foo/fs
date >> /foo/fs/datefile
ls -li /foo/fs/datefile # Find the inode number of datefile
zdb -ddddd foo/fs 8 # Find the DVA of datefile's L0 block
zdb -R foo/fs 0:32600:200
What should be displayed:
Found vdev: /dev/dsk/c2t2d0s0
0:32600:200
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
000000: 53657074656d6265 722032322c203230 September 22, 20
000010: 31362030383a3532 3a303620414d204d 16 08:52:06 AM M
000020: 44540a0000000000 0000000000000000 DT..............
...
What's actually displayed:
Found vdev: /dev/dsk/c2t2d0s0
0:32600:200
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
000000: 65626d6574706553 3032202c32322072 September 22, 20
000010: 32353a3830203631 4d204d412036303a 16 08:52:06 AM M
000020: 00000000000a5444 0000000000000000 DT..............
...
Secondly, from inspection it looks like foreign endianness blocks will be displayed wrong. I can't test because I lack any BE hardware, but the code shows a double negative: when displaying a foreign-endian block both the legend and the data will be byteswapped. It would be sufficient just to byteswap the legend.
Updated by Alan Somers almost 6 years ago
This should be in the illumos-gate project, not site. But I can't change it now.
Updated by Bryan Horstmann-Allen over 3 years ago
- Project changed from site to illumos gate