flushing "anonymous" buffers over NFS is rejected by server
(more weird bugs with mmap-ing via NFS)
dillon at apollo.backplane.com
Wed Mar 22 20:20:35 UTC 2006
:So, the problem is, the dirtied buffers _sometimes_ lose their owner and thus
:become root-owned. When the NFS client tries to flush them out, the NFS
:server (by default suspecting remote roots of being evil) rejects the
:flushing, which brings the client to its weak knees.
:1. Do the yet unflushed buffers really have to be anonymous?
:2. Can't the client's knees be strengthened in this regard?
Basically correct, though its not the buffers that get lost, its that
the VM pages get disconnected from the buffers when the buffers are
recycled, then get reconnected (sans creds info) later on.
The basic answer is that we don't want to strengthen the client
with regards to buffer/VM page creds, because buffers and VM pages
are cached items in the system and can potentially have many
different 'owners'. The entire cred infrastructure for buffers
was a terrible hack put into place many years ago, solely to support NFS.
It created a huge mess in the system code and didn't even solve
the problem (as you found out). I've already removed most of that junk
from DragonFly and I would argue that there isn't much point keeping it
in FreeBSD either.
The only real solution is to make the NFS client aware of the
restricted user id exported by the server by requiring that the
same uid be specified in the mount command the client uses to
mount the NFS partition. The NFS client would then use that user id
for all write I/O operations.
<dillon at backplane.com>
More information about the freebsd-stable