Bug 238112 - Unable to create ZVOL
Summary: Unable to create ZVOL
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.2-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-fs (Nobody)
Depends on:
Reported: 2019-05-25 00:38 UTC by Eugene Grosbein
Modified: 2020-08-24 17:54 UTC (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Eugene Grosbein freebsd_committer 2019-05-25 00:38:09 UTC
A colleague of mine is testing his set of virtual machines under FreeBSD 11.2-STABLE using bhyve (sysutils/vm-bhyve specifically) over GELI-encrypted non-boot ZFS pool with multiple ZVOLs and faced a problem.

After GELI attached the pool, kernel part of ZFS tastes its internals and writes to dmesg:

ZFS WARNING: Unable to create ZVOL sata/vm/ws2019tmplENhalts/C@20190524-225700-before-1st-reboot (error=63).

The dataset has recommended volmode=dev.

In sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c the function zvol_create_minor() prepends mentioned long name of dataset with prefix "zvol/" and calls make_dev_s() from sys/kern/kern_conf.c that is a wrapper for make_dev_sv() failing with ENAMETOOLONG (63).

make_dev_sv() uses prep_devname() that returns this error if total length is more than sizeof(dev->si_name) - 1 that equals to SPECNAMELEN defined to 63. So ZVOL name length is effectively limited to 58 octets due to "zvol/" prefix.

Warning message quoted above is too cryptic for user and this limit is obscure and seems to be FreeBSD-specific. Please change the code to test for ENAMETOOLONG  and issue a warning describing the problem more clearly.

Also, consider replacing kernel printf() with more useful logging like log() so the warning would hit syslog and get to /var/log/console.log (if enabled) and not dmesg buffer only.
Comment 1 Allan Jude freebsd_committer 2019-05-26 02:00:11 UTC
This error is about the snapshot, not the dataset itself. Did the dataset not get mounted as well?
Comment 2 Eugene Grosbein freebsd_committer 2019-05-26 17:10:15 UTC
(In reply to Allan Jude from comment #1)

There is no file system to mount, the dataset is a snapshow of another dataset with type=volume.
Comment 3 crest 2019-05-27 10:29:10 UTC
Try a shorter name. In FreeBSD < 12.0 the mount point length was quite short (IIRC 88 bytes).
Comment 4 mail 2019-05-27 10:50:07 UTC

I've been looking for a "fix" for quite some time now :


Does your comment imply that the limits involved have been altered/upped in 12.0 ?

Kind regards,

Comment 5 crest 2019-05-27 10:53:09 UTC
As part of the 64 Bit inode support a lot of those limits got increased (if you have to break the ABI make it count). IIRC the limit went from a few dozen bytes to 1024 in FreeBSD 12.
Comment 6 Eugene Grosbein freebsd_committer 2019-05-27 11:16:17 UTC
(In reply to crest from comment #3)

Have you actually read PR description? It is not about how to shorten the name. It is about warning message being too cryptic for user and limit being obscure.

And no, I've just checked stable/12 sources and they were not changed for this case: same mentioned function do same things and limit is SPECNAMELEN minus strlen("zvol/"). And SPECNAMELEN is still 63 in stable/12.
Comment 7 Eugene Grosbein freebsd_committer 2019-05-27 11:28:07 UTC
(In reply to crest from comment #3)

This is not about mounting anything. The dataset is volume, not file system.
Comment 8 Alexander Motin freebsd_committer 2019-05-28 14:00:31 UTC
Unfortunately SPECNAMELEN was bumped only in head (13). Too later to be merged into 12 due to ABI (or mostly KBI) breakage.  I agree that message may be not perfect, but error=63 means ENAMETOOLONG, which is hardto to interpret wrong once it is decoded.  I think we could add specific error message for that case.  In FreeNAS we just block those messages and limit ZVOL name lengths in external means.