Subject: Re: kqueue and NFS
To: Jaromir Dolecek <email@example.com>
From: Chuck Silvers <firstname.lastname@example.org>
Date: 09/28/2002 19:24:56
On Sat, Sep 28, 2002 at 09:52:53PM +0200, Jaromir Dolecek wrote:
> > I don't think polling is right, either. That will generate a lot of
> > annoying network traffic.
> > Instead, I would say "only support kevents for local writes of the file",
> > and document this behavior for the NFS case.
> Yes, it could be done this way, but it's lame to have to handle NFS
> specially in software.
> The polling shouldn't generate too much network traffic, not more
> than casual 'tail -f' causes for files on NFS. The polling would
> basically do just GETATTR RPC couple times per second for every
> file with registered kevents. Since there would be very few
> watched files, this shouldn't particularily affect the network.
I'd think that polling would be appropriate in this context,
since that's basically what apps would do before kqueue.
but at least with kqueue it's being done in the kernel
so that apps don't have to know about it. if kqueue doesn't do this
then kqueue is pretty much useless for NFS.
as for the polling frequency, I'd suggest using the same interval
as the NFS attribute cache timeout. if an application were stat()ing
an NFS file 10 times per second, the NFS client code would only query the
server again once every 5 to 60 seconds, so it seems sensible to get
more or less the same behaviour with kqueue. see NFS_ATTRTIMEO().