8.1-STABLE: problem with unmounting ZFS snapshots

Martin Matuska mm at FreeBSD.org
Sat Nov 13 11:06:33 UTC 2010


No, this is not good for us. Solaris does not allow "mounting" of
snapshots on any vnode, like we do. Solaris has them only in
.zfs/snapshots. This allows us to have read-only mounts without even
mounting the parent zfs.

Before v15 we have been happy with that code and had no issues :-)

I have a very simple testcase where just fixing the VFS_RELE breaks our
forced unmount. Let's say we use the correct VFS_RELE in zfs_vfsops.c:
VFS_RELE(vfsp->mnt_vnodecovered->v_vfsp);

Now let's say you have a mounted filesystem (e.g. md) under /mnt:
/dev/md5 on /mnt (ufs, local)

# mkdir /mnt/test
# mount -t zfs tank at t2 /mnt/test
# umount -f /mnt

Now you will hang because the second VFS_HOLD. So I stick to my opinion
that this "extra protection" is more a problem than a solution in our
case and it should be commented out.

Dňa 13.11.2010 11:27, Andriy Gapon  wrote / napísal(a):
> on 13/11/2010 04:27 Martin Matuska said the following:
>> Yes, this is indeed a leak introduced by importing onnv revision 9214
>> and it exists in perforce as well - very easy to reproduce.
>>
>> # mount -t zfs test at t1 /mnt
>> # umount /mnt (-> hang)
>>
>> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6604992
>> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6810367
>>
>> This is not compatible with mounting snapshots outside mounted ZFS and I
>> was not able to reproduce the errors defined in 6604992 and 6810367
>> (they are Solaris-specific). I suggest we comment out this code (from
>> head, later MFC and p4 as well).
>>
>> Patch (should work with HEAD and 8-STABLE):
>> http://people.freebsd.org/~mm/patches/zfs/zfs_vfsops.c.patch
> 
> Not quite sure, but perhaps it's better to make the logic in each place match
> the other.  That is, I see that the code does hold on a filesystem of a covered
> vnode, but does rele on a parent ZFS filesystem.
> Or is this kind of protection not needed at all for FreeBSD?
> 


More information about the freebsd-stable mailing list