Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 9 May 2016 10:15:27 -0700
From:      Bryan Drewery <bdrewery@FreeBSD.org>
To:        freebsd-fs@freebsd.org
Subject:   NFS inuse vnode sillyrename with > 1 links
Message-ID:  <b8a07958-85c1-2915-e33b-fbe14d54d2eb@FreeBSD.org>

next in thread | raw e-mail | index | archive | help
The context for this is in https://reviews.freebsd.org/D6254 with some
discussion already.

First my use-case:

cd some_nfs_dir/
mkdir src dst
touch src/foo
ln src/foo dst/foo
tail -F dst/foo &
rm -rf src/

This fails in rm/FTS (Directory not empty) in rmdir(1) since the removal
of src/foo renames it to src/.nfs*.  Then FTS tries to rmdir not
realizing there is a new file.

My real use-case is building Python in a temporary directory,
hardlinking it into a staging directory (for running from without
polluting /).  I then run the staging version of python for the rest of
the build.  If I try to rebuild Python while something else is running
the hard-linked Python from the staging directory then the Python build
fails since it is trying to rm -Rf a directory that just got a silly
rename, even though I was executing a different named link.  I
understand that a vnode inuse count is on the vnode and not the name,
but in this case I expect rm -Rf to just work since I wasn't running the
link being deleted.  Implementation complexities and history aside, this
should just work, even if it means a hack to FTS/rm rather than
nfs_remove.  It makes no sense from a user-perspective and has no sane
workaround except to not hardlink or use userland r/w locking to avoid
removing a binary in-use.

So to NFS.  I know nothing about the protocol or history.  I just know
that in this case it seems fine to not do a silly rename on a file if it
has multiple links, since the vnode will still be around to be used by
the kernel for in-use consumers.

--=20
Regards,
Bryan Drewery



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b8a07958-85c1-2915-e33b-fbe14d54d2eb>