ZFS ZVOLs missing

L

LoZio

Hi

Using
Code: 
FreeBSD xxx 9.0-RELEASE FreeBSD 9.0-RELEASE #0 AMD64

I did a zfs send of a ZVOL from a machine to another one. The transfer went ok, but on the receiving machine (with no other ZVOLs present) the /dev/zvol path was not present. If I create a new ZVOL the path appears, then I delete the ZVOL and whole /dev/zvol path is missing. zfs list shows the ZVOL.

As I read somewhere, I tried to rename the ZVOL with no success. It took a reboot to see the /dev/zvol/mypool/iscsi0 device.

Something wrong here.
Bye
 
The problem is not with the iscsi target itself, istgt says it cannot find /dev/zvol/mypool/iscsi0, and this is correct since the path /dev/zvol does not exist.

I had to reboot to have the path appear. After that the iscsi target found the vol with no problems. Sure I don't want to reboot after each zfs receive.
 
Yes I did. I made some test with my 350Gb zvols, then started with something more manageable. On the first transfer, the zvol does not exist on the destination, it is created on receive, so no rollback problems.
 
I don't use -R, it is not needed in my cfg. I transfer delta snapshot using -I, why should I use -R?
Also I'm used to work on [Open]Solaris, and when I transfer the snapshot (with the very same script) I normally find it on the receiving side.
I just can't think of the reboot being "by design".
 
I don't know why you should use -R... because I still don't know what send command you used. I don't know your level of expertise, or any example commands, so I can only guess.

For example (with made up numbers),

Code: 
zfs list

NAME              USED  AVAIL  REFER  MOUNTPOINT
tank             14.4T  17.6T  5.99G  /tank
tank/somezvol    23.1G  17.6T  23.1G  -

This would not work:
# zfs send tank ... | zfs recv ...
But this would
# zfs send tank -R ... | zfs recv ...
 
I used
[cmd=]zfs send -I mypool/iscsi0@20120415 mypool/iscsi0@20120416 | ssh root@bckserver zfs receive -v cloned/iscsi0[/cmd]

To be precise I piped it into mbuffer, as I usually do, but also tried without mbuffer and the result is just the same.
 
LoZio said:
I used
[cmd=]zfs send -I mypool/iscsi0@20120415 mypool/iscsi0@20120416 | ssh root@bckserver zfs receive -v cloned/iscsi0[/cmd]

To be precise I piped it into mbuffer, as I usually do, but also tried without mbuffer and the result is just the same.
Click to expand...

To elaborate a bit: mbuffer or not the zvol is transferred, but a corresponding /dev/zvol/mypool/iscsi0device does not show up until reboot.
 
Well, I think that command looks fine.

What versions of FreeBSD are you using?
# uname -a

What versions do you have for both zpool and zfs?
# zfs get version
# zpool get version

Did you ever upgrade, or just create in the current version?
# zpool history | grep upgrade
(So far, I found lots of problems related to log devices when you upgrade from pools created on FreeBSD 8.2, and a few others where we just blame the same thing but don't really know. But one pool I have with no logs was upgraded and is doing fine. My experience with zvols was very bad, so I am not using them at the moment [problems probably fixed sometime between Sept 2011 and Feb 2012 in 8-STABLE])

Do other zvols appear in /dev/zvol/... when you send them, or do all of them need a reboot?
 
peetaur said:
Well, I think that command looks fine.

What versions of FreeBSD are you using?
# uname -a

What versions do you have for both zpool and zfs?
# zfs get version
# zpool get version

Did you ever upgrade, or just create in the current version?
# zpool history | grep upgrade
(So far, I found lots of problems related to log devices when you upgrade from pools created on FreeBSD 8.2, and a few others where we just blame the same thing but don't really know. But one pool I have with no logs was upgraded and is doing fine. My experience with zvols was very bad, so I am not using them at the moment [problems probably fixed sometime between Sept 2011 and Feb 2012 in 8-STABLE])

Do other zvols appear in /dev/zvol/... when you send them, or do all of them need a reboot?
Click to expand...

uname is:
Code: 
FreeBSD -snip- 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:46:30 UTC 2012     
[email]root@farrell.cse.buffalo.edu[/email]:/usr/obj/usr/src/sys/GENERIC  amd64

zfs is 4 for non zvols, my zvol is
Code: 
NAME                         PROPERTY  VALUE    SOURCE
mypool/iscsi0                version   -        -

Zpool is v28 (your command does not work btw). It was upgraded from a v15 created on Solaris.

If I create a new zvol, it appears in /dev/zvol/mypool/xxx, eventually creating the /dev/zvol path. If I receive a zvol on the same host, the device does not appear. If I reboot the server, the received volume appears. This is pretty odd.
 
Yep, looks like my z* version commands were missing the pool name.

And I have no idea if v15 created on Solaris would have any issues. I only suspected it was from FreeBSD, where for 8.2 I know there are issues.

So, looks like you have a plan ol' software bug.

And in looking for more info, I found another guy with the same problem: http://forums.freebsd.org/showthread.php?t=24927

Unfortunately, I can't find anything about manually refreshing these devices... But you could try export and import instead of reboot.
 
peetaur said:
Yep, looks like my z* version commands were missing the pool name.

And I have no idea if v15 created on Solaris would have any issues. I only suspected it was from FreeBSD, where for 8.2 I know there are issues.

So, looks like you have a plan ol' software bug.

And in looking for more info, I found another guy with the same problem: http://forums.freebsd.org/showthread.php?t=24927

Unfortunately, I can't find anything about manually refreshing these devices... But you could try export and import instead of reboot.
Click to expand...

The zvols are in the same pool as other datasets. Cannot export without disrupting service...
Really disappointed with current implementation of ZFS on FreeBSD. I was in hurry to migrate my Solaris boxes, but I think I should remain there for some time. This and other bugs (see my other posts) make this an EXPERIMENTAL feature, nothing to rely on.
Thanks
 
To file a PR, first do a search: go to the top bar and under support, click "Bug Reports"

I couldn't find a PR mathing your problem (but that search is hard to use... treating spaces unlike a normal search engine).

Then file a PR by clicking "Submit Bug-report", which would take you here: http://www.freebsd.org/send-pr.html

And then fill in all the details. I assume what they are especially interested in is your "uname -a" output, and the specific steps to reproduce (and dtrace and things I don't know anything about, but they don't specifically ask for). If you say you need to import a Solaris v15 pool and upgrade it, maybe they will delay fixing it. So first try to reproduce it on a new pool, since that would be very fast... don't need to use ssh either, just make 2 pools locally.
 
Does it show up when you send the first snapshot? Meaning, without -I:
# zfs send mypool/myvol | ssh ... "zfs recv -d mypool"
 
You must log in or register to reply here.
Back
Top