Re: open() and ESTALE error
From: Andrey Alekseyev (uitm_at_blackflag.ru)
Date: 06/20/03
- Previous message: Andrey Alekseyev: "Re: open() and ESTALE error"
- In reply to: Don Lewis: "Re: open() and ESTALE error"
- Next in thread: Don Lewis: "Re: open() and ESTALE error"
- Reply: Don Lewis: "Re: open() and ESTALE error"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: truckman@FreeBSD.org (Don Lewis) Date: Fri, 20 Jun 2003 11:18:24 +0400 (MSD)
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, there are NFS-related functions in the VFS already. See
vfs_syscalls.c:getfh(), fhopen() and similar functions. There are things
related to NFS server in the UFS/FFS code too. So, I finally decided
that my "fix" doesn't do much harm to the above mentioned concept :)
> current working directory, and your current working directory is nuked
> on the server, vn_open will return ESTALE, and your patch above will
> loop forever.
It won't loop forever :) The "stale" integer is in there exactly for that
purpose :) In case of a stale current directory, open() will still return
ESTALE. In case of a file that was rm'd from the server, I believe
it'll return something different.
> If the rename on the server was done within the attribute validity time
> on the client, vn_open() will succeed even without your patch, but you
> may encounter the ESTALE error when you actually try to read or write
> the file.
Sure! But open() will succeed and probably you'll even be lucky to get
file contents from the cache. But that's another story, related to
attributes tuning (I have another patch for that:) However, even with
the existing FreeBSD NFS attribute cache behaviour, it's ok for me.
> server could do the rename while the client has the file open, after
> which some I/O operation on the client will encounter ESTALE.
Sure. That's perfectly understood. I'm not trying to solve all the
NFS inefficiencies related to heavily shared files.
> acdirmin/acdirmax, or a new handle timeout parameter. This may decrease
> performance, but nothing is free ...
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 name cache entry+other data
on ESTALE :) I may be wrong, though.
Anyway, thanks for the comments.
See also:
http://www.blackflag.ru/patches/nfs_attr.txt
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
- Previous message: Andrey Alekseyev: "Re: open() and ESTALE error"
- In reply to: Don Lewis: "Re: open() and ESTALE error"
- Next in thread: Don Lewis: "Re: open() and ESTALE error"
- Reply: Don Lewis: "Re: open() and ESTALE error"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
