Re: NFSv3 on freebsd<-->solaris
> 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 FreeBSD client can assume FreeBSD server. The NFS server is a simple thing that just do what the client requested, for example read the directory. Bugs in the FreeBSD NFS client is completely different story. > > Our NFS implementation on the client caches the NFS directory via the > buffer cache. It translates the cookies returned by the server to > a block number and offset as cached in the client's buffer cache. > > See nfs_readdirrpc() in sys/nfs/nfs_vnops.c > > This creates a directory-block abstraction on the client. The 'cookies' > the client returns to processes are based on this abstraction and do not > match the cookies returned by the server. > > The problem that we have is that our buffer cache abstraction essentially > fits a variable number of directory entries returned from the server. If > a file is created or deleted on the server, our buffer cache abstraction > gets thrown for a loop. The client _cannot_ depend on that if a file is created or removed on the server, the "bad cookie" error is returned in next readdir. RFC1813 does not require it in any way. > > In order to maintain consistency within the set of cached pages (note: > I'm not talking about cache coherency with the server here, just > consistency within the buffer cache on the client), our buffer cache > abstraction is currently dependant on the verifier key changing on the > server. I don't why it was done this way -- perhaps mtime was found to > not be sufficient. Maybe because it doesn't have sufficient resolution > under NFSv2. Under NFSv3 it should theoretically have sufficient > resolution but how many servers do you know keep the nanoseconds field > updated? I don't believe in it. First of all, NFSv2 has no verifiers, and work reasonably well. (There is a belief that NFSv2 is much more reliable than NFSv3, you know.) Then, invalidation of cached data is heavily depended on mtime anyway. The client don't do readdir RPC if it think that its cache is valid, it only verify the mtime. Finally, -current has a debugging printf in "bad cookie" handling code for about 4 months, and noone complain that his logs filled with the message. I think I now understand why the "bad cookie" handling code don't do the right thing. Removing files in the directory effectively shift its content to the left. So, if you read the directory and remove files in the same time, you will miss some entries. > When applied to files, the use of mtime to determine when to flush the > cache is nothing more then an inconvenience. But the use of mtime to > determine when to flush a directory cache can be fatal. I still don't see why. > If you want to change the way our directory verifier works, you have to > completely rewrite the directory caching code for the client. I think > you can argue that the verifier is not being implemented properly, but > I'm not going to let anyone change it unless the directory caching code > on the client is rewritten at the same time to use the server's cookies > directly. Really? > Right now the server's cookies are only used by the client to demark > client-buffer-cache buffer boundries. The actual cookies returned to > the *process* running on the client are translated from the client's > buffer cache abstraction of the NFS directory. > > The change that would have to be made would be for the server's cookies > to be passed through all the way to the process sitting on the client > rather then translated in the buffer cache. Then cache consistency in > our client would then not be as sensitive to the varying amounts of > information the server sends us and we could safely leave the verifier > alone on the server. This would require us to change the abstraction our > client uses significantly -- it would not longer be able to use the > cookies passed to it by the user process as direct offsets into the > client's buffer cache. Hmm. I don't think such a big changes in the directory caching is necessary at all, though I didn't actually think about it. Anyway, the verifiers only add to the breakage (see above). Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd<-->solaris
: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 and not monotonic. The server cannot :> tell the difference between a new rpc, a retry, or several different :> processes on the client scanning the same directory (running at different :> points in the directory). : :With the local applications, VOP_READDIR cannot tell the difference :too. There may be several program scanning one directory, the program :may do seekdir(), the only known thing is the uio_offset, that is the :cookie. First of all, the positional information returned by the various directory calls is only good for the life of the open descriptor. This descriptor is stateful. Under NFS, file descriptors (actually 'handles') are stateless. :> :> * An NFS readdir rpc can only approximate cache coherency, but that :> doesn't mean you can throw cache coherency out the window. : :What cache coherency? Noone ever mmap() a directory, I hope. After :getdirentries() syscall finished, someone may change the directory in :any way (just after read() call and a regular file). After the nfs :readdir reply sent to the client, someone may change the directory in :any way. Again, I don't see any difference. Nobody said anything about mmap(). The client system -- A FreeBSD client system - has a buffer cache. The buffer cache holds an abstraction for both files and directories. Our NFS implementation on the client caches the NFS directory via the buffer cache. It translates the cookies returned by the server to a block number and offset as cached in the client's buffer cache. See nfs_readdirrpc() in sys/nfs/nfs_vnops.c This creates a directory-block abstraction on the client. The 'cookies' the client returns to processes are based on this abstraction and do not match the cookies returned by the server. The problem that we have is that our buffer cache abstraction essentially fits a variable number of directory entries returned from the server. If a file is created or deleted on the server, our buffer cache abstraction gets thrown for a loop. In order to maintain consistency within the set of cached pages (note: I'm not talking about cache coherency with the server here, just consistency within the buffer cache on the client), our buffer cache abstraction is currently dependant on the verifier key changing on the server. I don't why it was done this way -- perhaps mtime was found to not be sufficient. Maybe because it doesn't have sufficient resolution under NFSv2. Under NFSv3 it should theoretically have sufficient resolution but how many servers do you know keep the nanoseconds field updated? When applied to files, the use of mtime to determine when to flush the cache is nothing more then an inconvenience. But the use of mtime to determine when to flush a directory cache can be fatal. - If you want to change the way our directory verifier works, you have to completely rewrite the directory caching code for the client. I think you can argue that the verifier is not being implemented properly, but I'm not going to let anyone change it unless the directory caching code on the client is rewritten at the same time to use the server's cookies directly. Right now the server's cookies are only used by the client to demark client-buffer-cache buffer boundries. The actual cookies returned to the *process* running on the client are translated from the client's buffer cache abstraction of the NFS directory. The change that would have to be made would be for the server's cookies to be passed through all the way to the process sitting on the client rather then translated in the buffer cache. Then cache consistency in our client would then not be as sensitive to the varying amounts of information the server sends us and we could safely leave the verifier alone on the server. This would require us to change the abstraction our client uses significantly -- it would not longer be able to use the cookies passed to it by the user process as direct offsets into the client's buffer cache. So, that's my position. You can 'fix' the verifier only if you fix the client along with it. It would be an excellent project. I might even have time to do it myself -- but not right now. If someone wants to take this on I'm willing to provide technical support! -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PRO
Re: NFSv3 on freebsd<-->solaris
> 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 getdirientries() call is monotonic, stateful, and > cache coherent. An NFS readdir rpc is stateless, not monotonic, and can > only approximate cache coherency. Perhaps I am mistaken, but I disagree. getdirentries() call is not monolitic and is stateless. Let see: To read a directory with the getdirentries() call, the application have to open it just like every over file and get a file descriptor. Like every over file descriptor, the open directory has associated offset, or pointer. The getdirentries() syscall supply the directory pointer to VOP_READDIR as uio_offset. (The cookie sent by NFS client is supplied to VOP_READDIR as uio_offset too.) After exit from VOP_READDIR, the uio_offset stored back in the file descriptor offset. The file offset is the only state saved. Note also that offset has nothing to do with the size of data transferred by getdirentries(), escpecially if the filesystem is not UFS. That is, the offset is actually just a handy place to store the cookie (OTOH, for any local filesystem I am aware of it indeed the offset in the physical directory.) 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 and not monotonic. The server cannot > tell the difference between a new rpc, a retry, or several different > processes on the client scanning the same directory (running at different > points in the directory). With the local applications, VOP_READDIR cannot tell the difference too. There may be several program scanning one directory, the program may do seekdir(), the only known thing is the uio_offset, that is the cookie. > > * An NFS readdir rpc can only approximate cache coherency, but that > doesn't mean you can throw cache coherency out the window. What cache coherency? Noone ever mmap() a directory, I hope. After getdirentries() syscall finished, someone may change the directory in any way (just after read() call and a regular file). After the nfs readdir reply sent to the client, someone may change the directory in any way. Again, I don't see any difference. > It > approximates cache coherency through the use of the verifier key. If > the verifier key supplied by the client is wrong, the server has to > tell it so. Otherwise the client's directory cache will get out of > sync. Nope, the verifier is for the server can validate the cookie. Cache validation need to be done my checking of mtime, like with regular files. What if the client cached all the directory, and then the directory has changed? So, the cache coherency with directories is no worse than with regular files. Note, that just like READ call return file attributes that can be used to cache validation, the READDIR call return the directory attributes, that can be used for this purpose. > Furthermore, the NFS readdir rpc has no notion of 'dead' directory entries > as far as I can tell. This means that from the point of view of an NFS > client, directories are always 'compacted'. Since clients may implement > a block cache for directories, the server cannot afford to return a valid > response if the verifier mismatches because it will screw up the client's > block cache for the directory. This is very different from the way most > local directories are scanned - filesystems such as UFS maintain dead > directory entries and thus allow a directory data block to be scanned > without any locking. We cannot use this trick with NFS. > > Add on top of that the fact that the NFS directory 'block size' may > different then a local filesystem's. NFS must translate padding > characteristics between the local filesystem and the NFS client's notion > of the directory. Even if we did support the notion of dead directory > entries in NFS, trying to translate the padding characteristics at the > same time would be fairly difficult to accomplish. Umm, I didn't understand that the translation has to do with the issue. BTW, not all local filesystems are UFS. > > :> Our NFS client used to have the same problem (a long time ago) and I put > :> code into it to re-read the directory if its cookies are stale. > : > :(According to a mail recently sent to -hackers, that doesn't work. > :In -current, the recovery code has a debugging printf(), so I guess > :the code only triggered in very rare cases (see above).) > > This works on FreeBSD clients as
Re: NFSv3 on freebsd<-->solaris
:> 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() syscall (on a local filesystems). 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 getdirientries() call is monotonic, stateful, and cache coherent. An NFS readdir rpc is stateless, not monotonic, and can only approximate cache coherency. * an NFS readdir rpc is stateless and not monotonic. The server cannot tell the difference between a new rpc, a retry, or several different processes on the client scanning the same directory (running at different points in the directory). * An NFS readdir rpc can only approximate cache coherency, but that doesn't mean you can throw cache coherency out the window. It approximates cache coherency through the use of the verifier key. If the verifier key supplied by the client is wrong, the server has to tell it so. Otherwise the client's directory cache will get out of sync. It may be fine to allow a directory cache to get out of sync given a single process on a client talking to the NFS server. It is not fine given multiple processes on a client talking to the NFS server and it is not fine given multiple clients. Furthermore, the NFS readdir rpc has no notion of 'dead' directory entries as far as I can tell. This means that from the point of view of an NFS client, directories are always 'compacted'. Since clients may implement a block cache for directories, the server cannot afford to return a valid response if the verifier mismatches because it will screw up the client's block cache for the directory. This is very different from the way most local directories are scanned - filesystems such as UFS maintain dead directory entries and thus allow a directory data block to be scanned without any locking. We cannot use this trick with NFS. Add on top of that the fact that the NFS directory 'block size' may different then a local filesystem's. NFS must translate padding characteristics between the local filesystem and the NFS client's notion of the directory. Even if we did support the notion of dead directory entries in NFS, trying to translate the padding characteristics at the same time would be fairly difficult to accomplish. :> Our NFS client used to have the same problem (a long time ago) and I put :> code into it to re-read the directory if its cookies are stale. : :(According to a mail recently sent to -hackers, that doesn't work. :In -current, the recovery code has a debugging printf(), so I guess :the code only triggered in very rare cases (see above).) This works on FreeBSD clients as far as I know. That is what I thought that email sent to hackers said... that it works w/ FreeBSD clients but not with certain Sun clients. :Anyway, I don't actually care what is correct NFS client behavior. I am :saying that sending "bad cookie" error is not useful for FreeBSD sever. : :Dima My understanding is that it is part of the protocol spec. We are not going to become incompatible with the spec. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd<-->solaris
[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 never "reject" the offset, and everyone is happy. > > (Not to mention NFSv2, where we never reject a client's cookie too). > > So, what we are trying to achieve by rejecting a NFSv3 client's cookie? > > Notify the client that the directory contents may have been compacted and > therefore that their seek offsets are now wrong. You apparently missed my above paragraph. Do we notify a local process about such a condition? Then, what is so special about compacting? What if I quickly moved out a directory content and replaced it with something completely different? How you can recover after it? With rm -r, the recovery is easy, but how the recovery will work if the program is, say, du? > 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() syscall (on a local filesystems). > The client should be careful to > avoid holding directory entry cookies across operations > that modify the directory contents, such as REMOVE and > CREATE. > > It seems to me that the solaris client is holding directory cookies across > a REMOVE operation and therefore should expect to get stale cookie errors > occaisionally. Yes. FreeBSD programs typically use fts(3), which read whole directory before return its content to the application. That is, the rule is honored. But this solution is in the userland. > Our NFS client used to have the same problem (a long time ago) and I put > code into it to re-read the directory if its cookies are stale. (According to a mail recently sent to -hackers, that doesn't work. In -current, the recovery code has a debugging printf(), so I guess the code only triggered in very rare cases (see above).) Anyway, I don't actually care what is correct NFS client behavior. I am saying that sending "bad cookie" error is not useful for FreeBSD sever. Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd<-->solaris
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 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 never "reject" the offset, and everyone is happy. > (Not to mention NFSv2, where we never reject a client's cookie too). > So, what we are trying to achieve by rejecting a NFSv3 client's cookie? Notify the client that the directory contents may have been compacted and therefore that their seek offsets are now wrong. > > > Instead of > > recovering, the solaris client barfs. Its a solaris bug really > > IMHO, it is very arguable. Why the client should "recover" after "stale > cookie" error, but should not recover after "stale filehandle" error? > How should it perform the recovery: If a reliable recovery is possible, > why it is not done on the server? Stale cookie is completely different from stale filehandle and in general it isn't possible to recover on the server. > > (After all, Sun know how NFSv3 should work, since they wrote the spec, > right? :-|) >From rfc1813: In the NFS version 3 protocol, each READDIR request includes both a cookie and a cookie verifier. For the first call, both are set to 0. The response includes a new cookie verifier, with a cookie per entry. For subsequent READDIRs, the client must present both the cookie and the corresponding cookie verifier. If the server detects that the cookie is no longer valid, the server will reject the READDIR request with the status, NFS3ERR_BAD_COOKIE. The client should be careful to avoid holding directory entry cookies across operations that modify the directory contents, such as REMOVE and CREATE. It seems to me that the solaris client is holding directory cookies across a REMOVE operation and therefore should expect to get stale cookie errors occaisionally. Our NFS client used to have the same problem (a long time ago) and I put code into it to re-read the directory if its cookies are stale. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd<-->solaris
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. The offset in the directory is essentially the cookie that would be sent to an NFS client. But we never "reject" the offset, and everyone is happy. (Not to mention NFSv2, where we never reject a client's cookie too). So, what we are trying to achieve by rejecting a NFSv3 client's cookie? > Instead of > recovering, the solaris client barfs. Its a solaris bug really IMHO, it is very arguable. Why the client should "recover" after "stale cookie" error, but should not recover after "stale filehandle" error? How should it perform the recovery: If a reliable recovery is possible, why it is not done on the server? (After all, Sun know how NFSv3 should work, since they wrote the spec, right? :-|) Dima Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd<-->solaris
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, built on Aug 3), and a Solaris 2.7 > :client. I run into problems when trying to use NFSv3 mounts on the > :client. Trying to remove files from the mounted partition (on the nfs > :client) results in multiple errors, for example: > : > :# rm -r /home/2/vladimir > :rm: Unable to remove directory /home/2/vladimir/CVS/blowup/c: File exists > :rm: Unable to remove directory /home/2/vladimir/CVS/blowup: File exists > :rm: Unable to remove directory /home/2/vladimir/CVS/useradd: File exists > : > :I have tried using tcp and udp mount options with the same result. NFSv2 > :works fine. > : > :Solaris client has the latest patches applied. I would very much appreciate > :any comments on that. > > When you look at those directories on the server from the server are there any > files left over? > > If so then the rm -r is somehow missing some files and then is unable to > rmdir the directory because it isn't yet empty. This is probably because our server detects that the directory has been modified and rejects the solaris client's directory cookies. Instead of recovering, the solaris client barfs. Its a solaris bug really but perhaps we can add a knob to relax our directory modified checks. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd<-->solaris
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)? > > > >The NLM version 4 protocol is not supported, I am working on this. > > > >Question: did you delete both checks after the Solaris 2.5 mention? > >or just one? which one? > > > >-Alfred > > > > > > Ah, so vers=4 has nothing to do with NFS's vers 3. >From reading the Open Group's XNFS book, NFSv3 clients use the NLM version 4 protocol to gain locks, FreeBSD's rpc.lockd doesn't have stub functions for NLMv4 locking _yet_ :) > > I have deleted both checks. > Interesting... > Please let me know if you need more info or testing done. Soon enough. :) thank you, -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd<-->solaris
>From [EMAIL PROTECTED] Wed Aug 25 01:11:10 1999
>Delivered-To: [EMAIL PROTECTED]
>Delivered-To: [EMAIL PROTECTED]
>Date: Tue, 24 Aug 1999 21:21:27 -0400 (EDT)
>From: Alfred Perlstein <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>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
>> /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 another problem. mailx on solaris
>> client could not lock the mailbox file anymore. The snoop output is
>> below (I am not an NFS guru, but hope it will be useful to somebody).
>> Here galileo is the FBSD server, galois is a Solaris 7 NFS client.
>> 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)?
>
>The NLM version 4 protocol is not supported, I am working on this.
>
>Question: did you delete both checks after the Solaris 2.5 mention?
>or just one? which one?
>
>-Alfred
>
>
Ah, so vers=4 has nothing to do with NFS's vers 3.
I have deleted both checks.
Please let me know if you need more info or testing done.
Vladimir
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd<-->solaris
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 another problem. mailx on solaris > client could not lock the mailbox file anymore. The snoop output is > below (I am not an NFS guru, but hope it will be useful to somebody). > Here galileo is the FBSD server, galois is a Solaris 7 NFS client. > 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)? The NLM version 4 protocol is not supported, I am working on this. Question: did you delete both checks after the Solaris 2.5 mention? or just one? which one? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd<-->solaris
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 another problem. mailx on solaris client could not lock the mailbox file anymore. The snoop output is below (I am not an NFS guru, but hope it will be useful to somebody). Here galileo is the FBSD server, galois is a Solaris 7 NFS client. 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)? Vladimir PS I am not sure these questions are appropriate for this list, please direct me to some other resource if this is not the case. Thanks! galois.math.uic.edu -> galileo.math.uic.edu NFS C LOOKUP3 FH=6CF3 Maildir galileo.math.uic.edu -> galois.math.uic.edu NFS R LOOKUP3 OK FH=20ED galois.math.uic.edu -> galileo.math.uic.edu NFS C GETATTR3 FH=9EF4 galileo.math.uic.edu -> galois.math.uic.edu NFS R GETATTR3 OK galois.math.uic.edu -> galileo.math.uic.edu NFS C GETATTR3 FH=B452 galileo.math.uic.edu -> galois.math.uic.edu NFS R GETATTR3 OK galois.math.uic.edu -> galileo.math.uic.edu NFS C GETATTR3 FH=107B galileo.math.uic.edu -> galois.math.uic.edu NFS R GETATTR3 OK galois.math.uic.edu -> galileo.math.uic.edu NFS C LOOKUP3 FH=92D1 vladimir galileo.math.uic.edu -> galois.math.uic.edu NFS R LOOKUP3 OK FH=6CF3 galois.math.uic.edu -> galileo.math.uic.edu NFS C LOOKUP3 FH=6CF3 Mailbox galileo.math.uic.edu -> galois.math.uic.edu NFS R LOOKUP3 OK FH=0BEF galois.math.uic.edu -> galileo.math.uic.edu NFS C LOOKUP3 FH=6CF3 Mailbox galileo.math.uic.edu -> galois.math.uic.edu NFS R LOOKUP3 OK FH=0BEF galois.math.uic.edu -> galileo.math.uic.edu PORTMAP C GETPORT prog=100021 (NLM) vers=4 proto=UDP galileo.math.uic.edu -> galois.math.uic.edu PORTMAP R GETPORT port=1005 galois.math.uic.edu -> galileo.math.uic.edu NLM C LOCK4 OH=1FAB FH=0BEF PID=4106 Region=0:0 galileo.math.uic.edu -> galois.math.uic.edu RPC R (#17) XID=4282729491 Program number mismatch (low=1, high=3) galois.math.uic.edu -> galileo.math.uic.edu PORTMAP C GETPORT prog=100021 (NLM) vers=4 proto=UDP galileo.math.uic.edu -> galois.math.uic.edu PORTMAP R GETPORT port=1005 galois.math.uic.edu -> galileo.math.uic.edu NLM C UNLOCK4 OH=1FAC FH=0BEF PID=4106 Region=0:0 galileo.math.uic.edu -> galois.math.uic.edu RPC R (#21) XID=4282729493 Program number mismatch (low=1, high=3) > >From [EMAIL PROTECTED] Tue Aug 24 03:44:09 1999 > >Delivered-To: [EMAIL PROTECTED] > >Delivered-To: [EMAIL PROTECTED] > >Date: Mon, 23 Aug 1999 20:44:39 -0700 (PDT) > >From: Matthew Dillon <[EMAIL PROTECTED]> > >To: "David 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 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 problems when trying to use NFSv3 mounts on the > >:client. Trying to remove files from the mounted partition (on the nfs > >:client) results in multiple errors, for example: > >: > >:# rm -r /home/2/vladimir > >:rm: Unable to remove directory /home/2/vladimir/CVS/blowup/c: File exists > >:rm: Unable to remove directory /home/2/vladimir/CVS/blowup: File exists > >:rm: Unable to remove directory /home/2/vladimir/CVS/useradd: File exists > >: > >:I have tried using tcp and udp mount options with the same result. NFSv2 > >:works fine. > >: > >:Solaris client has the latest patches applied. I would very much appreciate > >:any comments on that. > > > >When you look at those directories on the server from the server are there any > >files left over? > >There are files left over. > > > > >If so then the rm -r is somehow missing some files and then is unable to > >rmdir the directory because it isn't yet empty. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 well known problem. Please look at kern/5890 (by Remy Nonnenmacher). In our environment we had to use suggested patch to use FreeBSD as NFS server and Solaris NFS clients (v3). There was another discussion about it in the middle of November 1998 (initiated by me and followed by helpful answer from Remy) on -current mailing list. As I see, the kern/5890 is stopped with following question: Hi Remy, (Sat Apr 25 22:21:50 PDT 1998) Can you retest this bug? Peter made many changes to sys/nfs/nfs_serv.c over the summer. From the commit logs, I suspect it might be fixed. I can answer: Yes, the problem is still here (3.2-RELEASE and -CURRENT). I am closely observing cvs logs and looking for fix because this is unpleasant bug for us - but latest fix for readdirplus() still didn't help... (What about new kernel compilation option SOLARIS_NFSV3 or new sysctl variable? :-) -- Rudolf Cejka ([EMAIL PROTECTED]; http://www.fee.vutbr.cz/~cejkar) Brno University of Technology, Faculty of El. Engineering and Comp. Science Bozetechova 2, 612 66 Brno, Czech Republic To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd<-->solaris
>From [EMAIL PROTECTED] Tue Aug 24 03:44:09 1999
>Delivered-To: [EMAIL PROTECTED]
>Delivered-To: [EMAIL PROTECTED]
>Date: Mon, 23 Aug 1999 20:44:39 -0700 (PDT)
>From: Matthew Dillon <[EMAIL PROTECTED]>
>To: "David 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 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 problems when trying to use NFSv3 mounts on the
>:client. Trying to remove files from the mounted partition (on the nfs
>:client) results in multiple errors, for example:
>:
>:# rm -r /home/2/vladimir
>:rm: Unable to remove directory /home/2/vladimir/CVS/blowup/c: File exists
>:rm: Unable to remove directory /home/2/vladimir/CVS/blowup: File exists
>:rm: Unable to remove directory /home/2/vladimir/CVS/useradd: File exists
>:
>:I have tried using tcp and udp mount options with the same result. NFSv2
>:works fine.
>:
>:Solaris client has the latest patches applied. I would very much
appreciate
>:any comments on that.
>
>When you look at those directories on the server from the server are
there any
>files left over?
There are files left over.
>
>If so then the rm -r is somehow missing some files and then is unable to
>rmdir the directory because it isn't yet empty.
I've run snoop on the client. Client's hostname is smb2 (Solaris 7), server is
galileo (FBSD 3.2-STABLE, built on Aug 3).Output is below:
smb2.math.uic.edu -> galileo.math.uic.edu NFS C LOOKUP3 FH=2C5A vladimir
galileo.math.uic.edu -> smb2.math.uic.edu NFS R LOOKUP3 OK FH=9714
smb2.math.uic.edu -> galileo.math.uic.edu NFS C GETATTR3 FH=2C5A
galileo.math.uic.edu -> smb2.math.uic.edu NFS R GETATTR3 OK
smb2.math.uic.edu -> galileo.math.uic.edu NFS C GETATTR3 FH=9714
galileo.math.uic.edu -> smb2.math.uic.edu NFS R GETATTR3 OK
smb2.math.uic.edu -> galileo.math.uic.edu NFS C READDIR3 FH=9714 Cookie=0 for 1048
galileo.math.uic.edu -> smb2.math.uic.edu NFS R READDIR3 OK 3 entries (No more)
smb2.math.uic.edu -> galileo.math.uic.edu NFS C LOOKUP3 FH=9714 CVS
galileo.math.uic.edu -> smb2.math.uic.edu NFS R LOOKUP3 OK FH=6447
smb2.math.uic.edu -> galileo.math.uic.edu NFS C ACCESS3 FH=6447read (read)
galileo.math.uic.edu -> smb2.math.uic.edu NFS R ACCESS3 OK (read)
smb2.math.uic.edu -> galileo.math.uic.edu NFS C GETATTR3 FH=6447
galileo.math.uic.edu -> smb2.math.uic.edu NFS R GETATTR3 OK
smb2.math.uic.edu -> galileo.math.uic.edu NFS C ACCESS3 FH=6447lookup (lookup)
galileo.math.uic.edu -> smb2.math.uic.edu NFS R ACCESS3 OK (lookup)
smb2.math.uic.edu -> galileo.math.uic.edu NFS C READDIR3 FH=6447 Cookie=0 for 1048
galileo.math.uic.edu -> smb2.math.uic.edu NFS R READDIR3 OK 3 entries (No more)
smb2.math.uic.edu -> galileo.math.uic.edu NFS C LOOKUP3 FH=6447 blowup
galileo.math.uic.edu -> smb2.math.uic.edu NFS R LOOKUP3 OK FH=8AB2
smb2.math.uic.edu -> galileo.math.uic.edu NFS C GETATTR3 FH=8AB2
galileo.math.uic.edu -> smb2.math.uic.edu NFS R GETATTR3 OK
smb2.math.uic.edu -> galileo.math.uic.edu NFS C LOOKUP3 FH=8AB2 c
galileo.math.uic.edu -> smb2.math.uic.edu NFS R LOOKUP3 OK FH=1C3C
smb2.math.uic.edu -> galileo.math.uic.edu NFS C GETATTR3 FH=1C3C
galileo.math.uic.edu -> smb2.math.uic.edu NFS R GETATTR3 OK
smb2.math.uic.edu -> galileo.math.uic.edu NFS C READDIR3 FH=1C3C Cookie=0 for 1048
galileo.math.uic.edu -> smb2.math.uic.edu NFS R READDIR3 OK 9 entries (More)
smb2.math.uic.edu -> galileo.math.uic.edu NFS C READDIR3 FH=1C3C Cookie=1536 for 1048
galileo.math.uic.edu -> smb2.math.uic.edu NFS R READDIR3 OK 17 entries (No more)
smb2.math.uic.edu -> galileo.math.uic.edu NFS C LOOKUP3 FH=1C3C print_ineq.c,v
galileo.math.uic.edu -> smb2.math.uic.edu NFS R LOOKUP3 OK FH=4B03
smb2.math.uic.edu -> galileo.math.uic.edu NFS C ACCESS3 FH=4B03modify,extend
(modify,extend)
galileo.math.uic.edu -> smb2.math.uic.edu NFS R ACCESS3 OK (modify,extend)
smb2.math.uic.edu -> galileo.math.uic.edu NFS C REMOVE3 FH=1C3C print_ineq.c,v
galileo.math.uic.edu -> smb2.math.uic.edu NFS R REMOVE3 OK
smb2.math.uic.edu -> galileo.math.uic.edu NFS C LOOKUP3 FH=1C3C print_mult_list.c,v
galileo.math.uic.edu -> smb2.math.uic.edu NFS R LOOKUP3 OK FH=A985
smb2.math.uic.edu -> gal
Re: NFSv3 on freebsd<-->solaris
:... :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 problems when trying to use NFSv3 mounts on the :client. Trying to remove files from the mounted partition (on the nfs :client) results in multiple errors, for example: : :# rm -r /home/2/vladimir :rm: Unable to remove directory /home/2/vladimir/CVS/blowup/c: File exists :rm: Unable to remove directory /home/2/vladimir/CVS/blowup: File exists :rm: Unable to remove directory /home/2/vladimir/CVS/useradd: File exists : :I have tried using tcp and udp mount options with the same result. NFSv2 :works fine. : :Solaris client has the latest patches applied. I would very much appreciate :any comments on that. When you look at those directories on the server from the server are there any files left over? If so then the rm -r is somehow missing some files and then is unable to rmdir the directory because it isn't yet empty. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NFSv3 on freebsd<-->solaris
I'm forwarding this to [EMAIL PROTECTED] as I know many people are on the list that live in multi-platform worlds. - Forwarded message from [EMAIL PROTECTED] - Solaris 7 machines cannot use NFSv3 mounts from a FreeBSD NFS server. When using NFSv2 the decrease in performance was very noticeable. I was wondering if anyone among FreeBSD developers is aware of this problem (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 problems when trying to use NFSv3 mounts on the client. Trying to remove files from the mounted partition (on the nfs client) results in multiple errors, for example: # rm -r /home/2/vladimir rm: Unable to remove directory /home/2/vladimir/CVS/blowup/c: File exists rm: Unable to remove directory /home/2/vladimir/CVS/blowup: File exists rm: Unable to remove directory /home/2/vladimir/CVS/useradd: File exists I have tried using tcp and udp mount options with the same result. NFSv2 works fine. Solaris client has the latest patches applied. I would very much appreciate any comments on that. - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
