rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bernd Schubert
Subject: Re: [rdiff-backup-users] Encountering the NFS "Directory not empty" error
Date: Sun, 30 Oct 2005 01:23:21 +0200
User-agent: KMail/1.8

Hi Nick,

On Saturday 29 October 2005 23:21, Nick Parker wrote:
> After using rdiff for daily backups for the last couple weeks, I've run
> into the problem described at
> http://cvs.lp.se/doc/rdiff-backup/FAQ.html#dir_not_empty
>
> It appears to be triggered by removal of a directory in the production
> copy, which creates problems when the backup copy tries to duplicate the
> removal.
>
> I am not able to perform the backup outside of NFS, as we are doing this
> in case of a local server failure while also conforming to existing
> internal network infrastructure. Is there a known workaround for this
> issue? Has it been resolved in the 1.1 series? If the answer to these is
> "no", are there alternative backup systems similar in functionality to
> rdiff-backup? (preferably with support for diffs of binary files, like
> what rdiff-backup uses)
>
> Thanks!

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*

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.
Well a workaround, yes there is one, mount your nfs-directory without locking 
support (-olock on linux). But be carefull, other applications which may need 
locking support, will have their own problems then.

Cheers,
        Bernd



-- 
Bernd Schubert
PCI / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg





reply via email to

[Prev in Thread] Current Thread [Next in Thread]