Boot fails from an rpool on Hitachi 4k sector drives
The drives are two Hitachi Desktar 7K1000 D drives in a mirrored pool. They are novel in that they have a single platter, but I do not see why that should make a difference.
The reason I do not think that this is the same problem as bug 1772 (OI cannot import a data zpool created by S11X) is that installation of OI fails on this drive. The drive is recognized by the installer and can be selected, but creation of a pool fails. I was able to create a pool and write to it however by using zpool(1) and zfs(1) while running OI from the live CD.
The way I got OI BEs on these drives was that I had a mirrored pool of Seagate drives with both OI and S11E BEs on it. When one of the drives failed, I replaced it with a Hitachi drive and allowed a resilver to proceed under S11. (Before doing this, I upgraded from S11E to S11.) Then I replaced the other Seagate drive with an identical Hitachi drive in the pool. Needless to say, I can mount the OI BEs under S11. I am at zpool version 28.
This is the error message produced when trying to boot OI:
NOTICE: zfs_parse_bootfs: error 22 Cannot mount root on rpool/588 fstype zfs panic[cpu0]/thread=fffffffffbc2f260: vfs_mountroot: cannot mount root Warning - stack not written to the dump buffer fffffffffbc718e0 genunix:vfs_mountroot+33e () fffffffffbc71910 genunix:main+136 () fffffffffbc71920: unix:_locore_start+90 () panic: entering debugger (no dump device, continue to reboot)
By using kmdb, I was able to determine that what is failing is vdev_open. The calling order is zfs_parse_bootfs (zfs_vfsops.c) -> dsl_dsobj_to_dsname (dsl_dataset.c) -> spa_open (spa.c) -> spa_open_common -> spa_load_best -> spa_load -> spa_load_impl -> vdev_open (vdev.c).
Updated by Alex Viskovatoff almost 9 years ago
zdb produces the following:
Updated by Albert Lee almost 9 years ago
Because ashift is only used in the DMU allocation path, it's probably a sane to permit a smaller ashift in the label (we should still be able to read back the unaligned blocks) and use ours anyway. Whether to write the corrected ashift back to the label is a different question.