Date: Sun, 5 Apr 2009 18:25:46 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: zachary.loafman@isilon.com Cc: arch@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org> Subject: Re: VOP_LEASE Message-ID: <Pine.GSO.4.63.0904051734190.28966@muncher.cs.uoguelph.ca> In-Reply-To: <20090405201048.GB6319@isilon.com> References: <20080412021209.W43186@desktop> <alpine.BSF.2.00.0904051829490.12639@fledge.watson.org> <20090405201048.GB6319@isilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 5 Apr 2009, zachary.loafman@isilon.com wrote: > > I haven't had a chance to dig into the code, but can you explain how the > v4 server is granting delegations without something like VOP_LEASE? This > was actually a conversation I was going to prep for prior to BSDcan. We > already have a cluster-coherent oplock mechanism for CIFS, and we were > planning on trying to hook that in with v4 delegations, but our FS very > much needs VOP calls to accomplish things like delegations. We can't use > a local lease manager. > Good question. At the moment my code simply assumes that nothing else in FreeBSD is doing Open/Share locks and my server just tracks them itself and, if enabled, issues delegations to clients so they can do them locally. If other things, like a CIFS server, are going to be doing them as well, I think there would need to be some sort of "Windows-like lock manager" that both/all services share. I don't know if it should live below the VFS layer (it's not a file system, but a lock manager). It almost seems like it needs its own kernel API that the varous servers use. (I'll admit, since POSIX clients just always Open/Deny_none, which means essentially "no open lock", I haven't much worried about it. There is only one Windows nfsv4 client out there and I don't know if they ever do Open/Deny other than none.) Obviously, if anything else in FreeBSD is going to be handling Open Shares, that isn't sufficient. (For those not familiar with them, Open Shares are a Windowsism where Open write/Deny write opens a file for writing, but doesn't allow anyone else to open it for writing until it is closed. I'm not a Windoze guy, so I probably didn't get that quite right, but it gives you some idea of what is being talked about. A Delegation allows a client to do the Open Shares and byte range locking locally, without talking to the server. The delegation is recalled when a conflicting Open or byte range lock shows up from another client (or something else locally on the server).) The only thing my server code currently does is provide a function that can be called to recall a delegation. It currently only gets called before a local VOP_RENAME() in my code, but should also be called before local VOP_OPEN() and VOP_REMOVE(). However, this isn't sufficient if anything other than my server is issuing Open Share locks. It's an area that definitely needs some thought. (Then, there's mandatory byte range locking. Lets not even talk about that, for now:-) > Like I said, I need to look at code; it's very likely the existing > VOP_LEASE isn't right for us, anyways. > I don't think that VOP_LEASE() would be appropriate for this, since it all happens at the time of Open. (A call before VOP_RENAME() is necessary, since the nfsv4 Open uses a directory filehandle + component name and won't work after a file is renamed, since the client only knows the old name. A call before VOP_REMOVE() would be nice, so that a client doesn't allow an Open of a file already removed. However, it'll get an ESTALE shortly after opening it, anyhow.) Long winded, but hopefully not too confused, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0904051734190.28966>