On 04/10/18 16:51, Andriy Gapon wrote: > On 10/04/2018 22:48, Andrew Gallatin wrote: >> On 04/10/18 11:25, Andriy Gapon wrote: >>> On 10/04/2018 15:27, Andrew Gallatin wrote: >>>> Is there something like tools/diag/prtblknos for ZFS? >>> >>> zdb. >>> >>> It has a manual page, but in the case like this you typically want to run >>> zdb -d[d*] <ZFS filesystem name> <file's inode number> >>> Add d-s until you get all the information you want. >>> >>> It looks like five d-s is needed to get individual blocks reported. >>> >> >> Thanks for the instructions! >> >> How do I interpret this output: > [snip] >> 0 L1 1:1f01016c000:1000 20000L/1000P F=3 B=16769122/16769122 >> 0 L0 1:1f00f9e3000:20000 20000L/20000P F=1 B=16769122/16769122 >> 20000 L0 1:1f00fa03000:20000 20000L/20000P F=1 B=16769122/16769122 >> 40000 L0 1:1f00fa23000:20000 20000L/20000P F=1 B=16769122/16769122 > > The first number is an offset within the file (hex); Lx is a block level where > L0 is a data block, L1 is an indirect block just above data blocks, etc; x:y:z > is a (top-level) vdev number, a block offset on disk (hex) and a block size on > disk(hex); the rest is not as important. > > The quoted offsets appear to be just below 2TB. > > > Are these byte addresses? Or do I need to multiply by the blocksize to determine the offset into the file? From your "just below 2TB" I'm assuming byte addresses. This is a supermicro board X10SRA. They do have a f/w update, but I suspect it is mainly just for new ucode. Of course there is no changelong. I guess I'll try it if/when I'm totally unable to boot into a new BE. I just checked, and my EFI loader is ~1 year old, I should probably try updating that too. FWIW, I just updated to head again, and I see a problem with just one module, which looks like the attached. DrewReceived on Tue May 01 2018 - 12:34:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:15 UTC