From owner-freebsd-stable@FreeBSD.ORG Sat Nov 13 11:11:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 856F21065701; Sat, 13 Nov 2010 11:11:19 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6626C8FC08; Sat, 13 Nov 2010 11:11:17 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA12371; Sat, 13 Nov 2010 13:11:16 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PHE0q-000Mwy-MH; Sat, 13 Nov 2010 13:11:16 +0200 Message-ID: <4CDE7203.7090507@freebsd.org> Date: Sat, 13 Nov 2010 13:09:55 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Martin Matuska References: <4CDD2F5F.2000902@freebsd.org> <4CDD4EB4.40004@freebsd.org> <4CDDF77B.90708@FreeBSD.org> <4CDE6823.6080907@freebsd.org> <4CDE7133.6010803@FreeBSD.org> In-Reply-To: <4CDE7133.6010803@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.1-STABLE: problem with unmounting ZFS snapshots X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 11:11:19 -0000 on 13/11/2010 13:06 Martin Matuska said the following: > 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@t2 /mnt/test > # umount -f /mnt > > Now you will hang because the second VFS_HOLD. Hang here would be bad, I agree. But I think that the umount shouldn't succeed either, in this case. > 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. -- Andriy Gapon