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
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
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
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
> 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
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
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
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
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
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
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
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
> 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.
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
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
15 matches
Mail list logo
