Re: VOP_LEASE

* Jeff Roberson <jroberson@xxxxxxxxxxxxx> [080412 16:51] wrote:

On Sat, 12 Apr 2008, Alfred Perlstein wrote:

* Jeff Roberson <jroberson@xxxxxxxxxxxxx> [080412 16:13] wrote:
On Sat, 12 Apr 2008, Doug Rabson wrote:


On 12 Apr 2008, at 18:03, Kirk McKusick wrote:

Date: Sat, 12 Apr 2008 02:13:15 -1000 (HST)
From: Jeff Roberson <jroberson@xxxxxxxxxxxxx>
To: arch@xxxxxxxxxxx
Subject: VOP_LEASE

As far as I can tell this has never been used. Unless someone can show
me
otherwise I'm going to go ahead and remove it.

Thanks,
Jeff

VOP_LEASE is used by NQNFS and NFSv4. It notifies them when a file
is modified locally so that they know to update any outstanding
leases (e.g., evict any write lease for the file and do callbacks
for any read leases for the file). Deleting VOP_LEASE would break
NFS big time.

I think our NQNFS support might have been removed some time ago - I can't
see any calls to VOP_LEASE in the code right now. Something like
VOP_LEASE
would certainly be useful for a hypothetical future NFSv4 server. I
believe that samba could use it too for its oplocks feature which appears
to be similar to NQNFS's leases and NFSv4's delegations.

So the idea with delegations is that close() doesn't actually release the
file entirely to make future access cheaper?

My issue with VOP_LEASE is only that there are no in kernel
implementations of the VOP. I doubt it is applied regularly in syscalls.
It also seems odd that it is called without a lock.

Is the intent that the server will trap all accesses to a local vnode in
order to invalidate the client leases?

VOP_LEASE is supposed to implemented by a filesystem client.

For insance, NFS client with NQNFS would implement the VOP_LEASE
and trap those accesses to manage the lease with the remote server.

The remote server would get "lease RPCs" from the client and manage
the cache appropriately.

So why isn't this done within the actual VOP? If the lease expires
between calling VOP_LEASE and vn_lock(), VOP_READ() you have to do that
work all over again anyway.

I don't yet see why this is in filesystem independent code. I'm not
asserting that it doesn't need to be. I'd just like to understand it
better.

The reason to have it is to reduce code duplication and not to be
holding the vnode locks while doing the callbacks into the server
code.

Let me explain, the reason is 2-fold, one for reducing code duplication
and the other for avoiding holding locks for extended periods.

Consider a local client contending against a remote client for a
filesystem that supported leases.

Basically, each and every filesytem would have to explicitly do a
VOP_LEASE at the start of every routine that required notifying the
server making use of the underlying filesystem.

What you really wind up doing is having a vop_stdlocallease that
calls into a generic lease manager that does callbacks into any
server exporting that file.

So, if you move the lease call INTO the VOP_READ/READDIR/WRITE/etc
you wind up holding vnode locks while doing client communication
when contending with remote servers.

--
- Alfred Perlstein
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: [PATCH] VFS: new fgetattr() file operation
    ... We need this because fstat() semantics can in some cases be better ... implemented if the filesystem has the open file available. ... the server implemented as an unprivileged userspace process running on ... fstatis performed on open file descriptor on client ...
    (Linux-Kernel)
  • Re: VOP_LEASE
    ... for any read leases for the file). ... would certainly be useful for a hypothetical future NFSv4 server. ... NFS client with NQNFS would implement the VOP_LEASE ... and trap those accesses to manage the lease with the remote server. ...
    (freebsd-arch)
  • Re: UID/GID mapping system
    ... > would not export the filesystem to you. ... it more convenient for the client. ... servers and I want to mount something from one of the servers on my ... my laptop is EXACTLY the same as on the server. ...
    (Linux-Kernel)
  • Re: UID/GID mapping system
    ... > would not export the filesystem to you. ... it more convenient for the client. ... servers and I want to mount something from one of the servers on my ... my laptop is EXACTLY the same as on the server. ...
    (Linux-Kernel)
  • Re: [2/3] POHMELFS: Documentation.
    ... essentially as fast as underlying local filesystem. ... asynchronous and are sent to the server during system writeback. ... request comes from different client, ... are your writeback caches fully ...
    (Linux-Kernel)
Quantcast