Date: Fri, 2 Aug 1996 13:33:09 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dfr@render.com (Doug Rabson) Cc: terry@lambert.org, jkh@time.cdrom.com, tony@fit.qut.edu.au, freebsd-current@freebsd.org Subject: Re: NFS Diskless Dispare... Message-ID: <199608022033.NAA06190@phaeton.artisoft.com> In-Reply-To: <Pine.BSI.3.95.960802193906.21604L-100000@minnow.render.com> from "Doug Rabson" at Aug 2, 96 07:52:35 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The kernel is not currently reeentrant, and I think any underlying > > FS from an export will cause the block on the server. > > I am thinking of the VXLOCK case. I have been trying to construct a > scenario where the nfs client code ends up with an nfsnode which has been > freed by vclean() due to the lack of node locks. I haven't managed it yet > but I am sure there is one. I think the client side locking is maybe broken. There are a lot of evil things in the NFS client code, and you are right about the VXLOCK. I'd like to see each vnode reference treated as a counting semaphore increment, including the directory name cache references for the things. The vclean code is evil and redundant and redundant, but without moving the vnode allocation to per FS vnodes (I've mentioned this before), there is very little you can do. It's a buffer cache lose to say "no" to a page that's in core, but which does not have a vnode referencing it, so you have to reload it from disk even though a perectly good copy is already in memory. 8-(. > There is definately a problem with multiple processes appending to a file > over NFS due to nfs_write not being serialised by the lock. This is a non-problem. The file offset is maintained on the client and enforced in the uio... the offsets are part of the uio, so it is roughly equivalent to write( channel, buf, size, channel_offset). They should be atomic. I think the problem is that a previous append is not forcing an update to the file length for multiple appends. It's a protocol problem that's really only resolvable with advisory locking: client 1: get file size -> <- size is xxx :server client 2: get file size -> <- size is xxx :server client 1: <append write> write at offset xxx -> client 2: <append write> [ERROR case] write at offset xxx -> I hesitate to implement in-band reliance on a working locking implementation; I'd prefer an out-of-band contention resoloution of some kind by the clients. Technically, you could argue the same potential problem exists in a local machine for writev() interleaving by two processes. The length of the file baing appended will monotonically increase, but the write order is not guaranteed to not be mixed. I think the same soloution is applicable: out of band semaphoring between the contending processes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608022033.NAA06190>