A gotcha to avoid when using ZFS zvols as targets

[Dan Swartzendruber]

So I had created a 1TB vsphere lun and a 2TB veeam lun.  Ended up rebooting the esos server for other reasons.  Suddenly, vsphere hosts were complaining about the LUN not being signatured, and the veeam server couldn't find the "V" drive.  The esos gui was presenting /dev/zd0 and /dev/zd16 as the two luns (zd0 was the vsphere lun and zd16 the veeam lun).  If you look at /dev/zvol/POOL/z* you see:

lrwxrwxrwx    1 root     root             9 Oct  3 10:51 /dev/zvol/tank/veeam-zvol -> ../../zd0
lrwxrwxrwx    1 root     root            11 Oct  3 10:51 /dev/zvol/tank/veeam-zvol-part1 -> ../../zd0p1
lrwxrwxrwx    1 root     root            11 Oct  3 10:51 /dev/zvol/tank/veeam-zvol-part2 -> ../../zd0p2
lrwxrwxrwx    1 root     root            10 Oct  3 10:51 /dev/zvol/tank/vsphere-zvol -> ../../zd16
lrwxrwxrwx    1 root     root            12 Oct  3 10:51 /dev/zvol/tank/vsphere-zvol-part1 -> ../../zd16p1

e.g. they are backward now!  Must have been some kind of udev brain cramp?  So I stopped scst, edited the scst.conf file and replaced the /dev/zd0 and /dev/zd16 with the /dev/zvol/tank/vsphere and /dev/zvol/tank/veeam and started scst.  Rescanned the luns on vsphere, and voila!  The veeam server was also happy.  Word to the wise :)

[Marc Smith]

We should instead use a unique block device path like we do with SCSI
disks. Can you give me the output of these commands:
udevadm info --root --query symlink --name /dev/zd0
udevadm info --root --query symlink --name /dev/zd16


--Marc

> --
> You received this message because you are subscribed to the Google Groups
> "esos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to esos-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Dan Swartzendruber]

On 2015-10-03 15:21, Marc Smith wrote:
> We should instead use a unique block device path like we do with SCSI
> disks. Can you give me the output of these commands:
> udevadm info --root --query symlink --name /dev/zd0
> udevadm info --root --query symlink --name /dev/zd16

[root@esos ~]# udevadm info --root --query symlink /dev/zd0
/dev/tank/veeam-zvol /dev/zvol/tank/veeam-zvol
[root@esos ~]# udevadm info --root --query symlink /dev/zd16
/dev/tank/vsphere-zvol /dev/zvol/tank/vsphere-zvol

I will point out that the /dev/zvol/POOL/ZVNAME is standard practice
though...

[Brent Bolin]

This is interesting.  One of the few things I've liked about solaris is zfs.  But haven't messed with it on linux.  Prior is was fuser based but now I see it's kernel based.

Currently using mdadm with lvm and backend using vdisk_blockio on the logical volumes.   How are you using zfs?  fileio, blockio?  any performance difference between the two?  Think I'd prefer to use blockio because it makes the back-end look cleaner

[Dan Swartzendruber]

Blockio on zvol. Fileio would work the same since zfs does its own block io so Linux page cache is not in play. I have also used files in a zfs filesystem but they is more of a hassle and performance is about the same...

--
You received this message because you are subscribed to a topic in the Google Groups "esos-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/esos-users/LySxLxehajI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to esos-users+...@googlegroups.com.

[Marian Knichala]

I have the same problem. I created a few zvols and a blockio devices in the esos TUI on /dev/zdX. After I rebooting the /dev/zdX Device assignment changed. Is it possible to use the /dev/zvol/(zpool)/(zvol) device in the TUI?

[Marc Smith]

Yeah, that should be do-able using the udevadm command and looking up
the sym links like we do for SCSI disk devices... I just always
assumed that would be unique, but I guess not. =)

Do you mind putting in a feature request on GH and I'll get to it
soon? In the mean time, the work-around is to just edit /etc/scst.conf
by and use the udev provided symbolic link path, then run 'scstadmin
-config /etc/scst.conf' (or stop SCST first, modifying, then start).


--Marc

> You received this message because you are subscribed to the Google Groups
> "esos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Marc Smith]

The same issue occurs for MD arrays; can you try this patch and let me know:

diff --git a/tui/menu_common.c b/tui/menu_common.c
index bad4855..81d777e 100644
--- a/tui/menu_common.c
+++ b/tui/menu_common.c
@@ -1158,8 +1158,10 @@ char *getBlockDevChoice(CDKSCREEN *cdk_screen) {
if (block_dev_list->exitType == vNORMAL) {
/* Return a unique block device node */
SAFE_ASPRINTF(&block_dev, "/dev/%s", blk_dev_name[blk_dev_choice]);
- if ((strstr(block_dev, "/dev/sd")) != NULL) {
- /* Get a unique symbolic link to the SCSI disk */
+ if ((strstr(block_dev, "/dev/sd") != NULL) ||
+ (strstr(block_dev, "/dev/md") != NULL) ||
+ (strstr(block_dev, "/dev/zd") != NULL)) {
+ /* Get a unique symbolic link to the block device */
SAFE_ASPRINTF(&cmd_str,
"%s info --root --query symlink --name %s 2>&1",
UDEVADM_BIN, block_dev);


--Marc