getcwd lies on/under nfs4-mounted zfs dataset

[Sergey Kandaurov]

On 17 January 2013 04:42, Rick Macklem <rmacklem at uoguelph.ca> wrote:
> pluknet at 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