Date: Tue, 1 May 2018 15:38:20 -0400 From: Andrew Gallatin <gallatin@cs.duke.edu> To: Toomas Soome <tsoome@me.com> Cc: 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: <72d90b5c-59f9-ec6b-5726-7f3b79686f1a@cs.duke.edu> In-Reply-To: <E07FEFB9-7173-480A-A2CD-2D536AFE1598@me.com> 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> <d73e8b7b-3ffd-3f67-83d6-5a20ed84b704@cs.duke.edu> <E07FEFB9-7173-480A-A2CD-2D536AFE1598@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/01/18 13:14, Toomas Soome wrote: > > >> On 1 May 2018, at 17:34, Andrew Gallatin <gallatin@cs.duke.edu >> <mailto:gallatin@cs.duke.edu>> wrote: >> >> 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. >> > > could you test https://reviews.freebsd.org/D15207 Thank you so much! I just tried that, and I'm afraid that it didn't help, though by all rights I'd expect that it should. I installed the world into a new BE, and made sure to re-install boot1.efi into all my EFI partitions. Are you able to replicate this issue yourself? Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?72d90b5c-59f9-ec6b-5726-7f3b79686f1a>