[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rdiff-backup-users] Fwd: NFS "OSError: [Errno 39] reason and workaround
From: |
Troels Arvin |
Subject: |
[rdiff-backup-users] Fwd: NFS "OSError: [Errno 39] reason and workaround |
Date: |
Sun, 31 Oct 2004 00:17:30 +0200 |
User-agent: |
Pan/0.14.2.91 (As She Crawled Across the Table) |
Bernd Schubert has tried subscribing to this list, but without luck. - So
I forward the below quoted mail for him. Looks to me like valuable
information on the "Errno 30" problem which some people experience on
certain file systems (NFS, XFS, perhaps others).
/Troels
==================== mail-quote: ====================
From: Bernd Schubert <address@hidden>
To: address@hidden
Subject: list trouble and NFS "OSError: [Errno 39] reason and workaround
Date: Sat, 30 Oct 2004 23:25:24 +0200
Hello,
Well, I'm pretty new to rdiff-backup as I first installed and used it last
Monday. After rdiff-backup saved all files properly to a nfs-directory, it
faild with this "OSError [Errno 39]" message on the second run. After some
thinking about it, I guessed that its probably the locking daemon that causes
the trouble and remounted that directory without file locking, which
immediately made the problem going away. Since two days its working fine now,
thats not much time to be really sure, but maybe others on this list could
confirm it? You just need to give the 'nolock" option on mounting the
nfs-volume.
So whats the reason for the problem? Well, just an example, you have a
file /somewhere/somefile and open it or somefile is an executable and you
execute it. For some reason you decide to delete it (on the same machine
where its open or executed). The lock daemon will detect that this file is
still needed and will move your file to /somewhere/.nfs{some_random_letters}
and furthermore change the filedescriptors for the "deleted" file to
this .nfs.... file. Finally when the executable has finished or the open file
is closed, this .nfs.... file will be really deleted. (Disclaimer: I only
have some slight deeper knowledge about the nfs server and protocol itself,
but I do nothing know about the locking insights, a real expert might correct
me here).
Somehow I think that rdiff-backup opens a file in this directory, deletes this
file, deletes the directory and first then decides to close this file (if it
closes it at all).
Everyone so far could follow me? As I have absolutely no knowledge about
python, I hope someone on the list could help me finding the open/close code
of rdiff-backup. However, I can definitely state that I won't have one more
second time to care about rdiff-backup until November 15th.
Cheers,
Bernd
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [rdiff-backup-users] Fwd: NFS "OSError: [Errno 39] reason and workaround,
Troels Arvin <=