# ZFS ZVOLs missing



## LoZio (Apr 18, 2012)

Hi

*U*sing 
	
	



```
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


----------



## Sylhouette (Apr 18, 2012)

Could you show your iscsi target configuration file?

regards
Johan


----------



## LoZio (Apr 18, 2012)

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*.


----------



## Sylhouette (Apr 18, 2012)

Ok, clear.

Did you use -F on the receiving side?

*I*t should do the rollback and create the zvol.

gr
johan


----------



## LoZio (Apr 18, 2012)

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.


----------



## peetaur (Apr 18, 2012)

What was the send command used? Maybe you forgot to use -R for recursive.


----------



## LoZio (Apr 18, 2012)

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".


----------



## peetaur (Apr 18, 2012)

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), 


```
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 ...`


----------



## LoZio (Apr 18, 2012)

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 (Apr 18, 2012)

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.



To elaborate a bit: mbuffer or not the zvol is transferred, but a corresponding /dev/zvol/mypool/iscsi0device does not show up until reboot.


----------



## peetaur (Apr 18, 2012)

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?


----------



## LoZio (Apr 18, 2012)

peetaur said:
			
		

> Well, I think that command looks fine.
> 
> What versions of FreeBSD are you using?
> `# uname -a`
> ...



uname is:

```
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

```
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.


----------



## peetaur (Apr 18, 2012)

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 (Apr 18, 2012)

While looking for a workaround, you should also file a PR.


----------



## LoZio (Apr 18, 2012)

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.
> 
> ...



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


----------



## LoZio (Apr 18, 2012)

peetaur said:
			
		

> While looking for a workaround, you should also file a PR.



Could you direct me? Never done before but I would like to help.


----------



## peetaur (Apr 18, 2012)

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.


----------



## LoZio (Apr 18, 2012)

Done, thanks.


----------



## belon_cfy (Jul 21, 2012)

I'm having the same issue too. The received zvol never show in /dev/zvol/ folder.


----------



## phoenix (Jul 27, 2012)

Does it show up when you send the first snapshot? Meaning, without -I:
`# zfs send mypool/myvol | ssh ... "zfs recv -d mypool"`


----------

