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.
This error is about the snapshot, not the dataset itself. Did the dataset not get mounted as well?
(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.
Try a shorter name. In FreeBSD < 12.0 the mount point length was quite short (IIRC 88 bytes).
@crest: I've been looking for a "fix" for quite some time now : http://freebsd.1045724.x6.nabble.com/zfs-snapshot-make-dev-63-character-limit-td6147061.html Does your comment imply that the limits involved have been altered/upped in 12.0 ? Kind regards, Ruben
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.
(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.
(In reply to crest from comment #3) This is not about mounting anything. The dataset is volume, not file system.
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.
I'm no more in position to test or reproduce the problem.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=d8a259a74e52a1c77a92b514cebac172bf46428a commit d8a259a74e52a1c77a92b514cebac172bf46428a Author: Dave Cottlehuber <dch@FreeBSD.org> AuthorDate: 2022-11-16 23:07:43 +0000 Commit: Dave Cottlehuber <dch@FreeBSD.org> CommitDate: 2022-11-16 23:07:43 +0000 net/seaweedfs: update to 3.35 - hand over maintainership thank-you Boris! Reported by: portscout Sponsored by: SkunkWerks, GmbH PR: 238112 net/seaweedfs/Makefile | 17 ++++++++--------- net/seaweedfs/distinfo | 10 +++++----- 2 files changed, 13 insertions(+), 14 deletions(-)