[Top][All Lists]
[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