[OpenIndiana-discuss] rpool mirror moving to another ports

[Jim Klimov]

4 ноября 2014 г. 14:14:38 CET, "Nikola M." <minikola at gmail.com> пишет:
>On 11/ 4/14 12:01 PM, Jim Klimov wrote:
>> 4 ноября 2014 г. 7:41:59 CET, "Nikola M." <minikola at gmail.com> пишет:
>>> On 11/ 3/14 07:55 PM, Brogyányi József wrote:
>>>> Hi
>>>> I'd like to add a SSD to my pool but I need to move the rpool
>mirror.
>>> ZFS does not care at what port disks are pugged in and in what
>order.
>> Zfs doesn't care. Generally. For rpools, the import routine cares -
>it gets the single-device name from grub via kernel arguments to mount
>the rootfs and doesn't (initially?) import the pool completely. Hence
>all the problem and voodoo about rpool migrations with help of
>livecd's, etc.
>>
>> On my laptop it was worse - no CD, and when the USB was plugged in,
>"sd" (sata+usb) enumeration was different than without USB. So I had to
>stick with IDE/cmdk as it was consistent.
>Huh, there it is:
>http://wiki.openindiana.org/oi/How+to+migrate+the+root+pool
>
>So it is a more of a process then I was expected.
>
>How does it behaves anyway, if one installs on one disk and then adds 
>second HD/SSD as mirror on rpool.,
>if first disk fails or get removed, I would expect system to boot right
>
>away from second device that is on rpool?
>So if one has mirrored rpool and boot device fails, it still needs to 
>reroute device 2 in place of device1, to be able to boot from it?
>
>
>
>_______________________________________________
>openindiana-discuss mailing list
>openindiana-discuss at openindiana.org
>http://openindiana.org/mailman/listinfo/openindiana-discuss

IMHO and Theoretically at least, for the "static" controllers (whose enumeration does not change when some ports occupation changes when a drive dies or is added), the device path for the surviving disk in the pool should remain valid.

The chain of events is more or less this: BIOS (or chain-loading on more complicated systems) picks this drive to boot, control is passed to the Solaris GRUB via its boot-sector image and pointer to the partition with a (full replica of) rpool, and then grub's stripped-down zfs logic finds the (named in menu.lst) pool in the requested partition+slice, and the rootfs dataset (named or default via bootfs zpool attribute). There are historically a number of combinations of grub keywords and zpool attributes that can lead to the same results.

Finally grub gets the devicepath from the zpool header and the dataset number for rootfs, and passes these to the kernel -which imports an rpool and mounts a rootfs based on this data. That is, grub itself does "mount" enough of the rpool to get the correct kernel and bootarchive files, unpack them in memory as needed, and pass control with "command-line" parameters to the kernel. The part critical for disk migrations is the import by device-path. My hack-fu and understanding of zfs code were too weak when I tried to fix this up.

Sometime later in the process other replicas of the rpool are found and attached using hints from the zpool header and the pool guid probably.

So the current recommendation is to replug the disk(s), run another OS (live image, or a backported failsafe image like Firefly housed in the ramdisk and so not caring about full rpool support), run "zpool import -N rpool" and "zpool export rpool" and hope that disk device names now recorded in the zpool header are still relevant after the reboot.

For a mirror it might help to move one disk to the new hba, boot from the old one (assuming and hoping its device path still matches the opinion of the OS), then shut down and move the other disk while booting from the disk you reattached first. Hopefully this allows at oeast one disk to have stored usable pathnames across each reboot in the procedure.

Jim

--
Typos courtesy of K-9 Mail on my Samsung Android