> The client system -- A FreeBSD
> client system - has a buffer cache. The buffer cache holds an abstraction
> for both files and directories.
Well, the discussion is about FreeBSD NFS server, not about FreeBSD NFS
client. Neither FreeBSD server cannot assume FreeBSD client, nor
Fre
:Note that the application can do lseek on the directory, that is change
:the next cookie used. It is used by seekdir(). (And, of course, the
:application may lseek to anywhere it like, and the filesystem will have
:to deal with the bogus cookie.
:...
:
:> * an NFS readdir rpc is stateless a
> It isn't possible to do this and still remain synchronized. If the
> directory changes on the server, the client has no way of knowing
> whether a cookie corresponds to the same file if you always return
> a valid response. This breaks the protocol.
>
> A local filesystem
:> From rfc1813:
:>
:> If the
:> server detects that the cookie is no longer valid, the
:> server will reject the READDIR request with the status,
:> NFS3ERR_BAD_COOKIE.
:
:I propose that our cookies are always valid, just like directory
:offsets after getdirentries() sysca
[sorry for some delay...]
Doug Rabson wrote:
> > I think we should not ever reject a client's cookie. Consider a local
> > program that scan the directoty with the getdirentries() syscall. The
> > offset in the directory is essentially the cookie that would be sent to
> > an NFS client. But we
On Thu, 26 Aug 1999, Dmitrij Tejblum wrote:
> Doug Rabson wrote:
> >
> > This is probably because our server detects that the directory has been
> > modified and rejects the solaris client's directory cookies.
>
> I think we should not ever reject a client's cookie. Consider a local
> program
Doug Rabson wrote:
>
> This is probably because our server detects that the directory has been
> modified and rejects the solaris client's directory cookies.
I think we should not ever reject a client's cookie. Consider a local
program that scan the directoty with the getdirentries() syscall. T
On Mon, 23 Aug 1999, Matthew Dillon wrote:
> :...
> :am not implying that the problem might be on the FreeBSD side, it might
> :as well be a bug in solaris NFS implementation).
> :
> :I would greatly appreciate any help with the following problem. I have
> :a FreeBSD NFS server (3.2-STABLE, b
On 25 Aug 1999 [EMAIL PROTECTED] wrote:
> >> Why would solaris machine make a request with vers=4:
> >> galois.math.uic.edu -> galileo.math.uic.edu PORTMAP C GETPORT prog=100021
>(NLM) vers=4 proto=UDP
> >> ?
> >> (am I right that vers here is the same as the NFS version)
TED]
>cc: [EMAIL PROTECTED]
>Subject: Re: NFSv3 on freebsd<-->solaris
>MIME-Version: 1.0
>
>On 24 Aug 1999 [EMAIL PROTECTED] wrote:
>
>> Following advice from Cejka Rudolf <[EMAIL PROTECTED]>, I have edited
On 24 Aug 1999 [EMAIL PROTECTED] wrote:
> Following advice from Cejka Rudolf <[EMAIL PROTECTED]>, I have edited
> /src/sys/nfs/nfs_syscalls.c (commented out the lines after the "Solaris 2.5"
> comment). The "File exists" errors went away, everything seemed normal,
> but then I ran into anot
IL PROTECTED]>
> >To: "David O'Brien" <[EMAIL PROTECTED]>
> >Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> >Subject: Re: NFSv3 on freebsd<-->solaris
> >
> >:...
> >:
David O'Brien wrote (1999/08/23):
> - - Forwarded message from [EMAIL PROTECTED] -
> Solaris 7 machines cannot use NFSv3 mounts from a FreeBSD NFS server.
> ...
> # rm -r /home/2/vladimir
> rm: Unable to remove directory /home/2/vladimir/CVS/blowup/c: File exists
> ...
Yes, this is very
id O'Brien" <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
>Subject: Re: NFSv3 on freebsd<-->solaris
>
>:...
>:am not implying that the problem might be on the FreeBSD side, it might
>:as well be a bug i
:...
:am not implying that the problem might be on the FreeBSD side, it might
:as well be a bug in solaris NFS implementation).
:
:I would greatly appreciate any help with the following problem. I have
:a FreeBSD NFS server (3.2-STABLE, built on Aug 3), and a Solaris 2.7
:client. I run into p
15 matches
Mail list logo
