Quoting "Russell Coker" <russell@coker.com.au>:
I have a Debian/Squeeze NFS server running kernel 2.6.32-5-xen-amd64 and a Debian/Unstable NFS client.
I just did "rm -rf" on a directory containing 4.2G of files that was mounted via NFS. It was a directory with three large files which were MP4 files captured from digital TV, I had watched them all recently with mplayer. df didn't report any more free space.
To get the space back I ended up commenting out the line from /etc/exports, running "exportfs -r", then umounting and mounting it. I didn't check whether the space was free after running "exportfs -r", it probably was.
It seems that I was caught by the issue of open file handles. NFS is stateless so it doesn't necessarily process deletion for some time to handle the case of a NFS client that is running processes with open file handles.
How long is this supposed to go for? Can I force NFS to give up such caching when I need the space sooner than NFS will free it?
As long as it isn't locked by another client (and then you're delete wouldn't have worked), the file should have been deleted on the server side, more or less immediately. ([1]depending on the asynchronous or synchronous mount option the server returns before or after local deletion [2] exception, it isn't deleted if it is opened locally by a process on the server) Other clients would get a stale file handle afterwards, probably not immediately if they cache on their end and do not write to it. At least that's how I remember correct "NFS manners" but the reality of NFS implementations interfered quite often with the idea how NFS _should_ work. Anyway, after looking through the Linux manpages, I cannot see any tuning parameter that could impact the server to work in the way you experienced. It looks more like a bug than a feature to me. Regards Peter