Odd ZFS boot module issue on r332158

[Andrew Gallatin]

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.

Drew