open() and ESTALE error

Hello, I've been trying lately to develop a solution for the problem with open() that manifests itself in ESTALE error in the following situation: 1. NFS server: echo "" > file01 2. NFS client: cat file01 3. NFS server: echo "" > file02 && mv file02 file01 4. NFS client: cat file01 (eithe

Re: open() and ESTALE error

Corrections: - the patch is against STABLE - I know the second lookup will fail if the *current* directory itself is stale :) > Could anyone please be so kind to comment this issue? In particular, I'd like to know if I need NDINIT before entering vn_open() again, as there are several comments thr

Re: open() and ESTALE error

Another correction: - statement below is valid for a configuration where nfsaccess_cache_timeout is generally less than acmin, otherwise chances are the failure will be VOP_OPEN while requesting new attributes by a call to VOP_GETATTR > which is called from vn_open(). If nfs_access() decides to "g

Re: open() and ESTALE error

In case anyone interested I wrote a "paper" for my own reference on the FreeBSD NFS open() and attribute cache behavior. It can be found here: http://www.blackflag.ru/patches/nfs_attr.txt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman

Re: open() and ESTALE error

Terry, Thanks much for you comments, but see below. > The real problem here is that you know you did an operation > on the file which would break the name/nfsnode relationship, > but did not flush the cached name and nfsnode data. nfs_request() actually calls cache_purge() on ESTALE, and vn_open

Re: open() and ESTALE error

Don, > I can't get very enthusiastic about changing the file system independent > code to fix a deficiency in the NFS implementation. You're right. But it appears to be hard and inefficient to fix NFS for this (I tried, though). It will certainly require to pass names below VFS. On the other hand

Re: open() and ESTALE error

Don, > One case where there is a difference between timing out old file handles > and just invalidating them on ESTALE: Frankly, I just didn't find any mechanism in the STABLE kernel that does "timing out" for file handles. Do you mean, it would be nice to have it or are you trying to point it ou

Re: open() and ESTALE error

> Eh, but the generation number for file1 should have been changed! This will I'm sorry, the generation number is not changed in your scenario. Thus, I believe if the sequence of actions on the server is mv file1 tmpfile mv file2 file1 mv tmpfile file1 like you described, it's safe to continue

Re: open() and ESTALE error

Terry, > The place to correct this is probably the underlying FS. I'd > argue that getting ESTALE is a poke with a sharp stick that > makes this more likely to happen. ;^). Initially I was going to "fix" the underlying FS (that is, the NFS code). But it's extremely hard to do "nice", because I

Re: open() and ESTALE error

Don, > old vnode and its associated file handle. If the file on the server was > renamed and not deleted, the server won't return ESTALE for the handle I'm all confused and messed up :) Actually, a rename on the server is not the same as sillyrename on the client. If you rename a file on the s

Re: open() and ESTALE error

Don, > When a file is renamed on the server, its file handle remains valid. Actually I was wrong in my assumption on how names are purged from the namecache. And I didn't mean an operation with a file opened on the client. And it actually happens that this sequence of commands will get you ENOENT

ld-elf/libc problem? (was: php3/php4 problem)

Hello, Two months ago, after a thorough tracking of commits to STABLE, I've built a 4.8-STABLE distribution. The distribution was built from sources cvsup'd on Jul 06, 2003 and was targeted to be an upgrade package for a large production site. While the customer was testing this distribution, a s

Re: File locking, closes and performance in a distributed file systemenv

ot;unsubscribe freebsd-hackers" in the body of the message > -- Andrey Alekseyev. Zenon N.S.P. Senior Unix systems administrator To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: swapoff?

care of the data. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> -- Andrey Alekseyev. Zenon N.S.P. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Creating a sysctl? (mission impossible)

> with a 2.5-yr-old port to 4-STABLE. > http://www-2.cs.cmu.edu/~dpetrou/research.html Btw, we still use it quite successfully with minor modifications on mass hosting backend servers. Currently, with 4.6-STABLE. It really makes a difference. -- Andrey Alekseyev. Zenon N.S.