Re: [rdiff-backup-users] Encountering the NFS "Directory not empty" error

[Ben Escoto]

>>>>> Bernd Schubert <address@hidden>
>>>>> wrote the following on Sun, 30 Oct 2005 01:23:21 +0200

> I'm pretty sure the NFS problem is actually a general problem, but
> which is hidden by most kernels/filesystems. Actually, rdiff-backup
> does not close some filehandles before it tries to delete the
> files. On most filesystems, the files and also parent directories
> still can be deleted, though to the user it only seems they are
> deleted - its still on the disk, only no *new* filedescriptors can
> be opened. Old filedescriptors still have full access. On nfs this
> is different since it goes over the network and since the
> nfs-protocol up to v3 has no native filelocking (NFSv4 has native
> filelocking, but I still didn't have the time to test it). So on NFS
> directories, the client kernel can't hide the deleted file as on
> other filesystems, but moves each file which is deleted, but which
> still has open filedescriptors (fd), to .nfs* files. Those .nfs
> files can't be deleted until the last fd with access to this file
> has been closed. Unfortunately of course, also the parent directory
> can't be deleted then... *This is then the acutual problem you will
> notice*

I had considered the possibility that rdiff-backup was failing to
close files, but I spent some time looking through the code and
couldn't find any loose files.  Also from the reports I've gotten it
seems this error occurs inconsistently, and at different places, even
though rdiff-backup is single-threaded and purely deterministic.

But your paragraph explains the mechanism well, and suggests that it's
an rdiff-backup problem after all.

> A few month ago I already tried to fix this, but did it wrong (due
> to my lack of Python knowledge), unfortutely my lack of time (need
> to finish my Ph.D. thesis as soon as possible, but there are still
> unsolved problems) prevented further me to look deeper into it :( I
> will really do another attempt this or the next weekend.

>From my perspective, the hard part seems to be replicating the problem
consistently, and figuring out exactly which file(s) are not getting
closed.  If you can do this (which should be doable with no Python
knowledge), then it may be easy for me or someone else to fix it.

Good luck with your thesis :-)


-- 
Ben Escoto

pgpPLaapgZZJw.pgp
Description: PGP signature