From owner-freebsd-fs@FreeBSD.ORG Fri Feb 5 01:12:38 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A17D106566B; Fri, 5 Feb 2010 01:12:38 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC238FC08; Fri, 5 Feb 2010 01:12:33 +0000 (UTC) Received: by ewy3 with SMTP id 3so1047366ewy.13 for ; Thu, 04 Feb 2010 17:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=HJRZ7Pd8B4v2j2xixwq6kBnQRfDbvopjPGH6W68c+AA=; b=gstA1lrKJm9F+0av5vdKpM0bGOMkoUs/rNoCcDcUTYMduhmarLX+opc41LVwIuaOdo YUVy5/vLtmZZc/2HmZ1XORCN3J+1HYkBgY1k485KOPP5HeFVTd0YApyPC+CxA0vhksny 05Vkl+pn+Wk6ywjBOr4imrxBHePg5b2SlaK4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=PzgNliGqtrl5/1SdSF1vsAg3CS7FoZtmLJE/ELh5rDazBZ97Tnfm8lJtsJaWHGIzBF BpRnEXDTrKgVgqe0ywLp/47TKkkj8LYqXUPwBV7S/v8zMTmva2mnYNlhCAXUE4vlHV9Z nqIpRKxXKT6/XZHPgvs+mB2laD+mNFFlbA4ig= Received: by 10.213.100.203 with SMTP id z11mr479ebn.43.1265332352553; Thu, 04 Feb 2010 17:12:32 -0800 (PST) Received: from localhost (lan-78-157-90-54.vln.skynet.lt [78.157.90.54]) by mx.google.com with ESMTPS id 7sm3780368eyb.26.2010.02.04.17.12.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Feb 2010 17:12:31 -0800 (PST) Date: Fri, 5 Feb 2010 03:12:26 +0200 From: Gleb Kurtsou To: Pawel Jakub Dawidek Message-ID: <20100205011226.GA2657@tops.skynet.lt> References: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.com> <20100204205546.GA1733@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <20100204205546.GA1733@garage.freebsd.pl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, Jaakko Heinonen Subject: Re: Unable to pwd in ZFS snapshot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 01:12:38 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On (04/02/2010 21:55), Pawel Jakub Dawidek wrote: > On Wed, Feb 03, 2010 at 11:14:37PM -0500, Randy Sofia wrote: > > `pwd` returns "No such file or directory" when browsing snapshot files. This > > was addressed in: > > http://lists.freebsd.org/pipermail/freebsd-fs/2009-February/005675.html but > > remains the same as of 8.0-RELEASE. > > > > I am wondering if this is the expected behavior or if this was left by the > > wayside. > > > > A work around is available as per the previous discussion: > > zfs set snapdir=visible volume > > > > Reproducible behavior: > > CANAAN# zfs snapshot pithos/media@0_day_ago > > CANAAN# cd /pithos/media/.zfs/snapshot/0_day_ago/ > > CANAAN# pwd > > pwd: .: No such file or directory > > CANAAN# uname -a > > FreeBSD CANAAN 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Fri Dec 18 00:38:33 UTC > > 2009 root@:/usr/obj/usr/src/sys/CANAAN amd64 > > It was reported to me by Jaakko some time ago, that r197513 (committed > by me) is responsible for this breakage. Unfortunately I had no time to > fix it yet. It looks like pwd gets puzzled by all inodes having the same inode number under .zfs/snapshot. Besides we're trying to hide a fact that each snapshot is actually a mount point. Comments in zfs_ctldir.c explain the inode numbering scheme under .zfs in detail, each snapshot node has to have unique inode number. Correct inode number is returned by READDIR call, but not by GETATTR for the same vnode. This breaks our pwd (getcwd). The patch attached adds a hack to VOP_GETATTR to return expected inode numbers. Also, with r197513 reverted all inode numbers are still the same, but it seems to work as expected. Unfortunately I have no OpenSolaris installed to verify if inode numbers are also the same there. I think I should file a PR for the issue, so it doesn't get lost, what do you think? > -- > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="zfs-snapshot-pwd.patch.txt" diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c index 7820293..bb7e0ae 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c @@ -1061,6 +1061,7 @@ zfsctl_snapshot_mknode(vnode_t *pvp, uint64_t objset) VN_HOLD(vp); zcp = vp->v_data; zcp->zc_id = objset; + gfs_file_set_inode(vp, objset); VFS_HOLD(vp->v_vfsp); VOP_UNLOCK(vp, 0); diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c index 4f61f5f..19a3738 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -2371,6 +2372,15 @@ zfs_getattr(vnode_t *vp, vattr_t *vap, int flags, cred_t *cr, zfs_fuid_map_ids(zp, cr, &vap->va_uid, &vap->va_gid); // vap->va_fsid = zp->z_zfsvfs->z_vfs->vfs_dev; vap->va_nodeid = zp->z_id; + /* + * XXX Should root inode number for every mounted zfs + * filesystem/snapshot be the same? + * VROOT flag gets removed from the vp in zfsctl_snapdir_lookup + */ + if (zfsvfs->z_issnap && zp->z_id == zfsvfs->z_root) { + vnode_t *svp = zfsvfs->z_vfs->mnt_vnodecovered; + vap->va_nodeid = gfs_file_inode(svp); + } if ((vp->v_flag & VROOT) && zfs_show_ctldir(zp)) links = pzp->zp_links + 1; else --4Ckj6UjgE2iN1+kY--