Date: Tue, 1 May 2018 10:34:49 -0400 From: Andrew Gallatin <gallatin@cs.duke.edu> To: Andriy Gapon <avg@FreeBSD.org>, Allan Jude <allanjude@FreeBSD.org>, freebsd-current@FreeBSD.org Subject: Re: Odd ZFS boot module issue on r332158 Message-ID: <d73e8b7b-3ffd-3f67-83d6-5a20ed84b704@cs.duke.edu> In-Reply-To: <ffe4e081-a087-bfd8-3063-3b4cbbb8b13e@FreeBSD.org> References: <b772ee51-b27c-6591-c925-b4abd19678e8@cs.duke.edu> <935ad20e-017c-5c34-61b4-9db58788a663@freebsd.org> <5316e5ea-17a2-2f23-3c88-1671f41b5642@cs.duke.edu> <00fd72d0-cb41-eaf7-347e-6f3423bb6008@FreeBSD.org> <ed5be5d5-9ce0-c8f0-90a3-1ba46dd87637@cs.duke.edu> <ffe4e081-a087-bfd8-3063-3b4cbbb8b13e@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d73e8b7b-3ffd-3f67-83d6-5a20ed84b704>