Bug 251578

Summary:	sysutils/zfstools warnings with ZVOLs
Product:	Ports & Packages	Reporter:	ml
Component:	Individual Port(s)	Assignee:	Bryan Drewery <bdrewery>
Status:	Closed DUPLICATE
Severity:	Affects Only Me	Flags:	bugzilla: maintainer-feedback? (bdrewery)
Priority:	---
Version:	Latest
Hardware:	Any
OS:	Any

Description ml 2020-12-04 14:24:43 UTC

I'm testing sysutils/zfstools, which will create hourly snapshots of all my ZFS pools, on a 12.2 box.

However, I see in the logs, every hour, the following messages:
> kernel: g_dev_taste: make_dev_p() failed (gp->name=zvol/zroot/vm/win10test/disk0@zfs-auto-snap_hourly-2020-11-28-16h00, error=63)
> kernel: g_dev_taste: make_dev_p() failed (gp->name=zvol/zroot/vm/win10test/disk0@zfs-auto-snap_hourly-2020-11-28-16h00p1, error=63)
> kernel: g_dev_taste: make_dev_p() failed (gp->name=zvol/zroot/vm/win10test/disk0@zfs-auto-snap_hourly-2020-11-28-16h00p2, error=63)
> kernel: g_dev_taste: make_dev_p() failed (gp->name=zvol/zroot/vm/win10test/disk0@zfs-auto-snap_hourly-2020-11-28-16h00p3, error=63)
> kernel: g_dev_taste: make_dev_p() failed (gp->name=zvol/zroot/vm/win10test/disk0@zfs-auto-snap_hourly-2020-11-28-16h00p4, error=63)

Now:

_ win10test is a zvol: I'm not really interested in it and I could disable snapshots on it (or even delete it), but I want to understand things;

_ looking for this in forums, I see someone suggesting error 63 means the snapshot name is too long; that's strange, as I've got even longer names (not zvol, though);

_ anyway, if it's true, I guess snapshot should not be created, but they are there; they also get deleted the next hour, since this volume is not in use, so there's really no change;

_ I tried this on a different machine (still at 12.1) and I get a different message:
> kernel: ZFS WARNING: Unable to create ZVOL zroot/vm/win10test/disk0@zfs-auto-snap_hourly-2020-11-28-16h00 (error=63).
Still the snapshots are there.

_ I guess ...p1, ...p2, ...p3, ...p4 refers to the partitions on the volume (in fact listed in /dev/zvol/zroot/vm/win10test/); I guess this should not be attempted at all;

_ I've seen https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215067 and it's quite scary. Do we have to pay attention not too create too long names?

Comment 1 Bryan Drewery freebsd_committer

2020-12-04 20:39:49 UTC

This is Bug 215067. It's harmless spam that should go away with FreeBSD 13.
 
When a snapshot is made it auto creates /datadata/.zfs/snapshot/<all snapshots> directories. That being ZFS itself, not zfstools.

# ls ~/.zfs/snapshot
./                                       zfs-auto-snap_daily-2020-12-04-00h07/    zfs-auto-snap_hourly-2020-11-23-18h00/   zfs-auto-snap_hourly-2020-11-30-14h00/   zfs-auto-snap_hourly-2020-12-02-16h00/   zfs-auto-snap_monthly-2020-04-01-00h28/  zfs-auto-snap_monthly-2020-12-01-00h28/
../                                      zfs-auto-snap_frequent-2020-12-03-16h45/ zfs-auto-snap_hourly-2020-11-23-22h00/   zfs-auto-snap_hourly-2020-11-30-15h00/   zfs-auto-snap_hourly-2020-12-03-13h00/   zfs-auto-snap_monthly-2020-05-01-00h28/  zfs-auto-snap_weekly-2020-11-08-00h14/
zfs-auto-snap_daily-2020-11-19-00h07/    zfs-auto-snap_frequent-2020-12-04-11h30/ zfs-auto-snap_hourly-2020-11-24-11h00/   zfs-auto-snap_hourly-2020-11-30-16h00/   zfs-auto-snap_hourly-2020-12-03-14h00/   zfs-auto-snap_monthly-2020-06-01-00h28/  zfs-auto-snap_weekly-2020-11-15-00h14/
zfs-auto-snap_daily-2020-11-20-00h07/    zfs-auto-snap_frequent-2020-12-04-11h45/ zfs-auto-snap_hourly-2020-11-24-12h00/   zfs-auto-snap_hourly-2020-11-30-17h00/   zfs-auto-snap_hourly-2020-12-03-19h00/   zfs-auto-snap_monthly-2020-07-01-00h28/  zfs-auto-snap_weekly-2020-11-22-00h14/
zfs-auto-snap_daily-2020-11-24-00h07/    zfs-auto-snap_frequent-2020-12-04-12h15/ zfs-auto-snap_hourly-2020-11-24-13h00/   zfs-auto-snap_hourly-2020-12-01-10h00/   zfs-auto-snap_hourly-2020-12-04-12h00/   zfs-auto-snap_monthly-2020-08-01-00h28/  zfs-auto-snap_weekly-2020-11-29-00h14/
zfs-auto-snap_daily-2020-11-25-00h07/    zfs-auto-snap_hourly-2020-11-23-14h00/   zfs-auto-snap_hourly-2020-11-25-10h00/   zfs-auto-snap_hourly-2020-12-01-15h00/   zfs-auto-snap_monthly-2020-01-01-00h28/  zfs-auto-snap_monthly-2020-09-01-00h28/
zfs-auto-snap_daily-2020-12-02-00h07/    zfs-auto-snap_hourly-2020-11-23-15h00/   zfs-auto-snap_hourly-2020-11-25-11h00/   zfs-auto-snap_hourly-2020-12-02-14h00/   zfs-auto-snap_monthly-2020-02-01-00h28/  zfs-auto-snap_monthly-2020-10-01-00h28/
zfs-auto-snap_daily-2020-12-03-00h07/    zfs-auto-snap_hourly-2020-11-23-16h00/   zfs-auto-snap_hourly-2020-11-25-12h00/   zfs-auto-snap_hourly-2020-12-02-15h00/   zfs-auto-snap_monthly-2020-03-01-00h28/  zfs-auto-snap_monthly-2020-11-01-00h28/


For the zvol /dev does not support long filenames so it hits an error of 63 (ENAMETOOLONG) because the .zfs/snapshot/<snapshot name> is too long.

In FreeBSD 13 it looks like there is a zfs property of snapdev to completely disable creating these per dataset.
     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.


For 12 I think you just have to ignore it.

Comment 2 Bryan Drewery freebsd_committer

2020-12-04 20:40:04 UTC


*** This bug has been marked as a duplicate of bug 215067 ***