Hi, we send snapshots from a host with (old) SmartOS to a FreeBSD 10.1. hw.machine: amd64 hw.model: Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz hw.ncpu: 12 hw.byteorder: 1234 hw.physmem: 68558307328 hw.usermem: 15738359808 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: amd64 hw.realmem: 70866960384 This server was never really rebooted after it went into production, so upon reboot (bringing it to 10.1-RELEASE-p41, to update it to 10.3-RELEASE afterwards), it was discovered that it couldn't import its zpool anymore. Lots and lots of g_dev_taste: make_dev_p() failed (gp->name=zvol/storage/backup/ahostnamehere/some-guid-disk1@zfs-auto-snap:daily-2016-11-22-00:00, error=63) It seems there is a 63 character limit in place here (judging from various post in mailing-lists). I booted with the 11.0 install CD and tried to mount the zpool with that (LiveCD mode) - it showed the same error messages. I'm updating it to 10.3 at the moment, for the sake of having it on a supported release. Is there any fix for this? We're not really in a position to rename the snapshots on the source-system.
This is harmless log spam. Unless you really need to be accessing zvol snapshots so conveniently. Just clone the zvol snapshot instead and it will work fine. OpenZFS in FreeBSD 13 has a snapdev property that should avoid this. snapdev=hidden|visible Controls whether the volume snapshot devices under /dev/zvol/<pool> are hidden or visible. The default value is hidden. snapdir=hidden|visible Controls whether the .zfs directory is hidden or visible in the root of the file system as discussed in the Snapshots section of zfsconcepts(8). The default value is hidden.
*** Bug 251578 has been marked as a duplicate of this bug. ***