On 29 Jun, I wrote:
> On 22 Jun, Andrey Alekseyev wrote:
>> Name cache can be purged by nfs_lookup(), if the latter finds that the
>> capability numbers doesn't match. In this case, nfs_lookup() will send a
>> new "lookup" RPC request to the server. Name cache can also be purged from
>> getnewvnod
On 22 Jun, Andrey Alekseyev wrote:
> 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 th
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
On 21 Jun, Andrey Alekseyev wrote:
> 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 sillyrenam
- Terry Lambert's Original Message -
> Specifically, see the underline part of:
>
> > > + if (error == ESTALE && stale++ == 0)
> ---
>
> ...he exits it after retrying it fails, and falls into the
> standard ESTALE return case.
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
On 20 Jun, Andrey Alekseyev wrote:
>> 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
On 20 Jun, Andrey Alekseyev wrote:
> 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 n
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 Lewis wrote:
> > +again:
> > error = vn_open(&nd, flags, cmode);
> > if (error) {
> > + /*
> > + * if the underlying filesystem returns ESTALE
> > + * we must have used a cached file handle.
> > + */
> > + if (error == E
Andrey Alekseyev wrote:
> 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
On 20 Jun, Andrey Alekseyev wrote:
> In the normal situation, namecache entry+vnode+nfsnode+file handle may
> stay cached for a really long time (until re-used? deleted or renamed
> on the *client*). Expiring file handles (a new mechanism?) means much the
> same to me as simply obtaining a new nam
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
On 19 Jun, Andrey Alekseyev wrote:
> 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 &
Andrey Alekseyev wrote:
> 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.
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
22 matches
Mail list logo
