Broken ZFS boot on upgrade

[Andriy Gapon]

On 11/11/2019 15:10, Jonathan Anderson wrote:
> On 11/11, Andriy Gapon wrote:
>> Could it be that you have 2TB+ disk(s) and a relatively old BIOS ?
> 
> The first two vdevs use 1 TiB disks, but the third vdev has 3 TiB disks, so that
> sounds like a possible explanation... perhaps the contents of /boot previously
> resided on one of the 1 TiB vdevs but the new /boot lives on the new vdev
> post-upgrade. Is there a zfs admin command to ask which vdev(s) a file or
> directory's blocks reside on?

You need to find out the inode number first (ls -i or stat -s).
Then you can use zdb -ddddd <zfs dataset> <inum>
For example:
$ zdb -ddddd rpool/ROOT/20171102 4557
...
               0 L1  0:16e1304000:2000 20000L/2000P F=102 B=26531456/26531456
               0  L0 0:2d155d000:20000 20000L/20000P F=1 B=26531456/26531456
           20000  L0 0:2d1c91000:20000 20000L/20000P F=1 B=26531456/26531456
           40000  L0 0:2d1cb1000:20000 20000L/20000P F=1 B=26531456/26531456
           60000  L0 0:129eeef000:20000 20000L/20000P F=1 B=26531456/26531456
           80000  L0 0:129f138000:20000 20000L/20000P F=1 B=26531456/26531456
           a0000  L0 0:129ef0f000:20000 20000L/20000P F=1 B=26531456/26531456
           c0000  L0 0:129f1c3000:20000 20000L/20000P F=1 B=26531456/26531456
           e0000  L0 0:129f2c6000:20000 20000L/20000P F=1 B=26531456/26531456
[... lots of ouput ...]
0:129f2c6000:20000 is a block pointer.
0 is a vdev number, typically it's n-th device zpool status output.
129f2c6000 is a hexadecimal offset within a vdev, in bytes.
20000 is a hexadecimal block size.

> My BIOS is from 2016, so not "old", but possibly old enough?

-- 
Andriy Gapon