From owner-freebsd-fs@FreeBSD.ORG Thu Jan 31 16:03:30 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2EDBAA64 for ; Thu, 31 Jan 2013 16:03:30 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by mx1.freebsd.org (Postfix) with ESMTP id D7DCFFD6 for ; Thu, 31 Jan 2013 16:03:29 +0000 (UTC) Received: by mail-qe0-f52.google.com with SMTP id 6so1349003qeb.11 for ; Thu, 31 Jan 2013 08:03:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=x/z3mYX3Z1sloFJ+we21eSXbSGsC6DXMvBFRlRI8018=; b=j4w3TgznRpGt8LSD7eFli+GGKzVLlbAntX6h81gYpbG5E7sqrJyXnYvLj+kqJqzqEA 9yYMdmOFfayRDaE44GL0CRHfPHjvK+K9vAHv+BpjrUJWL+Aih29vbLxcxOZVBQEIb2eA cT36kzn0qRKFhS/fxhV+VZ/5HsWbg7ekwCjB1L6jesTUIKFuzHDmdAWeKj2PvAWLr4vo K8wm/OnP51Hsl8Hrikp9x75XqQqlIKpz2VzQPN2ylq+9u5V3UhJY00nxXRVp1OZY4gHQ KzKNaRGrWNzO2Aw3iWpLlV2aNxQhwtiXV0nWm6TlBHrZV2DdZBAeJT68SrWI+P7Z+Wtm MpAg== MIME-Version: 1.0 X-Received: by 10.229.78.97 with SMTP id j33mr2252518qck.107.1359648202844; Thu, 31 Jan 2013 08:03:22 -0800 (PST) Received: by 10.229.78.96 with HTTP; Thu, 31 Jan 2013 08:03:22 -0800 (PST) In-Reply-To: <1171241649.2066788.1358383377496.JavaMail.root@erie.cs.uoguelph.ca> References: <1171241649.2066788.1358383377496.JavaMail.root@erie.cs.uoguelph.ca> Date: Thu, 31 Jan 2013 19:03:22 +0300 Message-ID: Subject: Re: getcwd lies on/under nfs4-mounted zfs dataset From: Sergey Kandaurov To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 16:03:30 -0000 On 17 January 2013 04:42, Rick Macklem wrote: > pluknet@gmail.com wrote: >> Hi. >> >> We stuck with the problem getting wrong current directory path >> when sitting on/under zfs dataset filesystem mounted over NFSv4. >> Both nfs server and client are 10.0-CURRENT from December or so. >> >> The component path "user3" unexpectedly appears to be "." (dot). >> nfs-client:/home/user3 # pwd >> /home/. >> nfs-client:/home/user3/var/run # pwd >> /home/./var/run >> > Ok, I've figured out what is going on. The algorithm in libc > works, but vn_fullpath1() doesn't. The latter assumes that > "mount points" are marked with VV_ROOT etc. For the > "pseudo mount points" (which are mount points within the > directory tree on the NFSv4 server), this isn't the case. > > If you: > sysctl debug.disablecwd=1 > sysctl debug.disablefullpath=1 > > it works. (At least for the UFS case I tested.) Thank you very much, Rick! As an interim solution, we've decided to go that way. > > I can't see how this can be made to work correctly > for vn_fullpath1() unless it was re-written to use the > same algorithm that lib/libc/gen/getcwd.c implements. > > I was pretty sure this used to work. Maybe the syscalls > used to be disabled by default or weren't used by the > libc functions? > > Anyhow, sorry about the cofusing posts while I figured > out what was going on, rick > ps: Don't use the patch I posted. It isn't needed and > will break stuff. > >> nfs-client:~ # procstat -f 3225 >> PID COMM FD T V FLAGS REF OFFSET PRO NAME >> 3225 a.out text v r r-------- - - - /home/./var/a.out >> 3225 a.out ctty v c rw------- - - - /dev/pts/2 >> 3225 a.out cwd v d r-------- - - - /home/./var >> 3225 a.out root v d r-------- - - - / >> >> The used setup follows. >> >> 1. NFS Server with local ZFS: >> # cat /etc/exports >> V4: / -sec=sys >> >> # zfs list >> pool1 10.4M 122G 580K /pool1 >> pool1/user3 on /pool1/user3 (zfs, NFS exported, local, nfsv4acls) >> >> Exports list on localhost: >> /pool1/user3 109.70.28.0 >> /pool1 109.70.28.0 >> >> # zfs get sharenfs pool1/user3 >> NAME PROPERTY VALUE SOURCE >> pool1/user3 sharenfs -alldirs -maproot=root -network=109.70.28.0/24 >> local >> >> 2. pool1 is mounted on NFSv4 client: >> nfs-server:/pool1 on /home (nfs, noatime, nfsv4acls) >> >> So that on NFS client the "pool1/user3" dataset comes at /home/user3. >> / - ufs >> /home - zpool-over-nfsv4 >> /home/user3 - zfs dataset "pool1/user3" >> >> At the same time it works as expected when we're not on zfs dataset, >> but directly on its parent zfs pool (also over NFSv4), e.g. >> nfs-client:/home/non_dataset_dir # pwd >> /home/non_dataset_dir >> >> The ls command works as expected: >> nfs-client:/# ls -dl /home/user3/var/ >> drwxrwxrwt+ 6 root wheel 6 Jan 10 16:19 /home/user3/var/ >> -- wbr, pluknet