Handling changes in device names

[Daniel]

I have a mirrored set of drives (/dev/hda and /dev/sdb SATA1), the
system boots from sda SATA0

I recently added 2 new bigger drives, one at a time to migrate the
existing pool (attach/detach).
Initially I installed the first new drive on SATA1, it was given
device /dev/sdb, and the original changed to /dev/sdc!

zpool status -v showed /dev/sdb as UNAVAIL. Switching the cables put
things back to normal, and the attach command worked perfectly
generating a 3-way mirror. But it did show 5 CKSUM errors for sdb?
Previously scrubbed weekly, so could this have been caused by ZFS
writes continuing on hda when the device names were changed and simply
needing to be fixed later?

Can ZFS automatically scan all of the devices to see which ones belong
together? As LVM does.

I am changing the drive layout to use a single DOS/Linux partition for
now so the pool can be used in Nexenta too - then it will be easier to
change to EFI in future if that provides a better method for auto-
detecting.
If I didn't want to share the pool, creating 2 LVM volume groups and
logical volumes would be another way to guarantee consistent device
names.

Daniel.

[Ricardo Martins]

I had the same problem a few weeks ago. I think that if you export the
pool with "zpool export" before changing drives and import it when you
boot the computer again, ZFS won't get mess up the drives in the pool.

At least doing that helped in my case (I had to connect everything like
it was in the beginning, export the pool, connect the new drive(s),
boot, import the pool and only then change the drives in the pool).
It's a bit of work, but works for me.

I don't know if this is a bug/not-implemented thing in ZFS-fuse or a bug
in ZFS proper.

Regards,
--
Ricardo Martins  ><><  scarybox.net ><>< GPG key: 0x1308F1B4

[Pawel Jakub Dawidek]

This is mostly likely a bit not implemented in ZFS-FUSE. ZFS first tries
to open components by remembered names/paths. If that fails, it tries to
lookup components by their IDs (for example disk serial number). I
needed to add code that allows to obtain disk serial number to FreeBSD
kernel, so I'm guessing its not implemented in linux port. As a
work-around you should be able to remove /etc/zfs/zpool.cache file and
import the pool (zpool export also removes pool from zpool.cache, that's
why it worked for you).

--
Pawel Jakub Dawidek http://www.wheel.pl
p...@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!

[Ricardo Martins]

On 8/11/07, Pawel Jakub Dawidek <p...@freebsd.org> wrote:

This is mostly likely a bit not implemented in ZFS-FUSE. ZFS first tries
to open components by remembered names/paths. If that fails, it tries to
lookup components by their IDs (for example disk serial number). I
needed to add code that allows to obtain disk serial number to FreeBSD
kernel, so I'm guessing its not implemented in linux port.  As a
work-around you should be able to remove /etc/zfs/zpool.cache file and
import the pool (zpool export also removes pool from zpool.cache, that's
why it worked for you).

--
Pawel Jakub Dawidek                       http://www.wheel.pl
p...@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

Oh. That makes sense. Thank you for clearing this up, Pawel.

[Aaron Grogan]

If you have a udev-based system, try adding devices by the symlinks
in /dev/disk/by-id/. This will ensure that zfs-fuse always tries to
access the disks by vendor, model and serial number. If you've already
set up your pool using conventional /dev/sd* and /dev/hd* names, stop
zfs-fuse, remove /etc/zpool.cache, and import with a command like:

zpool import -d /dev/disk/by-id tank

This way, your zpool.cache will remember disks with persistent names.

I'm away from my office at the moment and have lost access to my
workstation, but if I recall correctly, that's approximately what I did.

- Aaron

[Daniel]

zfs umount -a
zpool export tank

zpool import -d /dev/disk/by-id tank

This works well, thanks for you help.