From owner-freebsd-fs@FreeBSD.ORG Sun Feb 14 01:05:36 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 C93981065670; Sun, 14 Feb 2010 01:05:36 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id C2F328FC08; Sun, 14 Feb 2010 01:05:35 +0000 (UTC) Received: by fxm28 with SMTP id 28so21715fxm.31 for ; Sat, 13 Feb 2010 17:05:34 -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=r3dAXO2A9JvdobnPhW/NmJ1meoQ2QG8xRqOqw0Q4CPk=; b=CepLPdaz5yUHstP+Mvctiyml21+YMc0GJjUxCRTEWp1Yk1BcM8GpiZncFq78quu22M qhS4Oqg8XKc02EdwG0b2brnsUGg1UJleW7vFcu89tMUiekbzEoM3jTr8AZmAlXP2TQW3 Lv+rr4wtSVZKm8At/Jrzy/YUQ9tD0WQvkr/uw= 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=b+WM7inDPitXXqvWWbcXMzfe79nG0UYkZByxrwryUPvvvyHFONifYywAyf0StBGZrU r+phW7YsFYylSilX1IoRFNy6/fkNlxL6sSEKT2mdPr0dapglIigwhpI5rHVIZyfq3SMz mHhts+dSgpUUCNEOmbbcIs8N0LiPOCWbVf6V4= Received: by 10.223.5.207 with SMTP id 15mr1037622faw.6.1266109534835; Sat, 13 Feb 2010 17:05:34 -0800 (PST) Received: from localhost (lan-78-157-90-54.vln.skynet.lt [78.157.90.54]) by mx.google.com with ESMTPS id h2sm7924669fkh.2.2010.02.13.17.05.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 13 Feb 2010 17:05:31 -0800 (PST) Date: Sun, 14 Feb 2010 03:05:26 +0200 From: Gleb Kurtsou To: Jaakko Heinonen Message-ID: <20100214010526.GA11217@tops.skynet.lt> References: <4b473c1f1002032014y4da8c0f0xcb74c749332cced3@mail.gmail.com> <20100204205546.GA1733@garage.freebsd.pl> <20100205011226.GA2657@tops.skynet.lt> <20100210200922.GA3109@a91-153-117-195.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <20100210200922.GA3109@a91-153-117-195.elisa-laajakaista.fi> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek 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: Sun, 14 Feb 2010 01:05:36 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On (10/02/2010 22:09), Jaakko Heinonen wrote: > On 2010-02-05, Gleb Kurtsou wrote: > > 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. > > r196309 added a VOP_VPTOCNP(9) implementation for snapshots. However due > to changes made in r197513 zfsctl_snapshot_vptocnp() never gets called. > > There's also another problem with the hidden .zfs directory: if the > directory is not in the name cache, __getcwd() will fail. To reproduce > this set debug.vfscache sysctl to 0 before the directory enters to > cache. > > # sysctl debug.vfscache=0 > # cd /scratch/.zfs > # /bin/pwd > pwd: .: No such file or directory > > Here's a patch which tries to fix/work around these problems: > > http://people.freebsd.org/~jh/patches/zfs-ctldir-vptocnp.diff > > The patch needs more work and I have tested it only very lightly. I see no reason in implementing VPTOCNP for directories under .zfs. The problem here lies in incorrect inode numbers (inconsistency between VOP_READDIR and VOP_GETATTR). Fixing it only in kernel (__getcwd) doesn't necessarily fixes it for all cases in userland, getcwd in our libc falls back to comparing inode numbers (algorithm equivalent to default VOP_VPTOCNP implementation), besides I think midnight commander also performs something very similar with inode numbers. Fixing inode numbers would also fix pwd issues with namecache disabled. Here is what it looks like in my case (with patch from my previous email applied): /.zfs % testdir ./. 1 1 ./.. 1 3 !!! ./snapshot 2 2 /.zfs % cd snapshot /.zfs/snapshot % testdir ./. 2 2 ./.. 1 1 ./2009-12-25 205 205 ./2010-02-10 122 122 ^^^ These two are fixed by the patch. It would be 3 3 otherwise /.zfs/snapshot % cd 2009-12-25 /.zfs/snapshot/2009-12-25 % testdir ./. 3 205 !!! ./.. 3 2 !!! ./.cshrc 13102 13102 ./media 38 38 [...] /usr/bin % testdir | head ./. 85 85 ./.. 45 45 ./from 123257 123257 ./env 123223 123223 ./bzfgrep 470652 470652 ./nm 470564 470564 ./calendar 122923 122923 [...] testdir sources attached. What do you think about it? Do you by chance have OpenSolaris running to check if situation is different there? Thanks, Gleb. > > -- > Jaakko --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="testdir.c.txt" #include #include #include #include #include int main(int argc, char **argv) { char *path; char buf[MAXPATHLEN]; DIR *dirp; struct dirent de_buf; struct dirent *de; struct stat st; if (argc < 2) path = "."; else path = argv[0]; dirp = opendir(path); if (dirp == NULL) err(1, "opendir"); while (1) { if (readdir_r(dirp, &de_buf, &de) != 0) err(1, "readdir"); if (de == NULL) break; snprintf(buf, sizeof(buf), "%s/%.*s", path, de->d_namlen, de->d_name); if (lstat(buf, &st) == -1) err(1, "stat: %s, buf"); printf("%-20s\t%d\t%d\t%s\n", buf, de->d_fileno, st.st_ino, (de->d_fileno != st.st_ino ? "!!!" : "")); } closedir(dirp); return (0); } --+HP7ph2BbKc20aGI--