Date: Sat, 22 Mar 1997 13:55:59 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dfr@nlsys.demon.co.uk (Doug Rabson) Cc: terry@lambert.org, dfr@render.com, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@mx.ba-stuttgart.de Subject: Re: wd driver questions Message-ID: <199703222056.NAA19471@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.95.970322175811.333C-100000@kipper.nlsystems.com> from "Doug Rabson" at Mar 22, 97 06:21:35 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Leasing is a bit different. The VOP_LEASE is used by the filesystem > consumers to get read or write leases to the files before calling the > other vops. I am not sure how this would fit into an event mechanism. event_send( LEASE_REQUEST) -> <- event_reply( LEASE_GRANT) A reply is an event to a handler specified in the send (the event source instance, in C++ terms, with 'this' being passed as one of the event arguments...). > Life is slightly trickier for the NFS server since it doesn't keep track > of the cookies which it has handed out. The client keeps track. It is > hard for the server to distinguish between a cookie which is valid and one > which was not affected by any recent directory modifications. Keeping > track would involve too much complexity for very little gain, IMHO. This was not my meaning on lock range decoelesce. I was thinking in terms of a generation count in each directory block, maybe, as an implementation detail. > It is still much easier to invalidate all the cookies on a compaction. > What we can do is not invalidate the cookies when the directory is > extended. That would help some clients. This really depends on what FS events the SunOS NFS client is really implicitly modelling by it's behavior. We know that a directory modification that reorders or removes the referenced entry in a block containing a given cookie is one. We *don't* know under what circumstances it will *correctly* back off and reread. Really, we need a contact at Sun for this one... 8-(. > > Yes; I would like to see the objects move between the systems, actually, > > which is why I was talking about a vnode-as-fd based kernel file I/O > > subsystem with Mike the other day. > > Do you mean replacing the struct file with struct vnode? That seems > worthwhile but is really best treated as a totally different piece of > work. Well, if the interface is the same in the protected mode kernel and the boot support library, then the consumer code can be shared, even if we don't go so far as to share actual implementation beyond that. One problem here is that vnode's are seperate from in core inodes, and the probably shouldn't be (vclean re-rear's it's ugly head). Fixing this means adding a VOP_VRELE() for per FS vnode release, for when the inode and vnode pool are per FS, and the same entity. It implies a lot of things, like reference counting all vnodes that come out of the VFS barrier, including directory name cache references, as if they were "open" instances. > Again, I don't want to go too fast with this. Revamping disk partitioning > and proper support for removable devices can come later. Heh. Sorry... got carried away from finding a sympathetic ear. 8-). Regards, 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?199703222056.NAA19471>