Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Nov 2015 11:49:01 +0200
From:      Daniel Braniss <danny@cs.huji.ac.il>
To:        Alfred Perlstein <alfred@freebsd.org>
Cc:        Rick Macklem <rmacklem@uoguelph.ca>, Konstantin Belousov <kostikbel@gmail.com>, hackers@freebsd.org
Subject:   Re: kqueue of a nfs mounted file not working
Message-ID:  <FCEAD57F-38BC-4CF4-B0CF-7CE0E9571ED1@cs.huji.ac.il>
In-Reply-To: <564A8B6F.3080009@freebsd.org>
References:  <9BC3EFA2-945F-4C86-89F6-778873B58469@cs.huji.ac.il> <20151115152635.GB5854@kib.kiev.ua> <3AEC67FD-2E67-4EF9-9D46-818ABF3D8118@cs.huji.ac.il> <661673285.88370232.1447682409478.JavaMail.zimbra@uoguelph.ca> <564A8B6F.3080009@freebsd.org>

index | next in thread | previous in thread | raw e-mail


> On 17 Nov 2015, at 04:05, Alfred Perlstein <alfred@freebsd.org> wrote:
> 
> 
> 
> On 11/16/15 6:00 AM, Rick Macklem wrote:
>> Daniel Braniss wrote:
>>>> On 15 Nov 2015, at 17:26, Konstantin Belousov <kostikbel@gmail.com> wrote:
>>>> 
>>>> On Sun, Nov 15, 2015 at 11:22:55AM +0200, Daniel Braniss wrote:
>>>>> HI,
>>>>> I???m writing a program to monitor a file using kqueue(2), if the file is
>>>>> local
>>>>> all is OK, but if the file is via a nfs mounted fs, it only works once.
>>>>> stat shows the file growing, but kevent is not triggered.
>>>> Does file grow due to local changes on the nfs client, or some other
>>>> client changes the file, while your client tries to get kevent
>>>> notifications ?
>>> it gets updated by a host which has the file as local, so yes, it gets
>>> updated
>>> by another client/host.
>>> 
>> Hmm, I am not surprised that this doesn't work. The only indication to the
>> client that the file has changed on the server is a change in the file's
>> attributes when they're acquired (via a Getattr RPC or similar) from the server.
>> 
>> There is a vfs operation called VFS_SYSCTL(). This isn't implemented on
>> the current NFS client. It was implemented on the old one, but only for
>> NFS locking events and I didn't understand what needed to be done, so I
>> didn't do it.
>> Kostik, do you know if there is a VFS_SYSCTL() call done when the kevent
>> stuff is probing for a file size change? (Or does it not probe and events
>> get triggered via the write syscall or ???) I took a quick look at the kevent
>> stuff, but admit I got lost and couldn't figure out what triggered events
>> being logged?
>> 
>> Also, is the event for "file growing" or "file changed"?
>> If it is the latter, all the NFS client can do is look for a change in
>> the file's modify time and this is often at a resolution of 1sec., which
>> implies that a change within the same second as the previous one may not
>> be noticed. (NFSv4 has a Change attribute that is always guaranteed to
>> change, but that is only NFSv4.) Also, you see metadata changes as well
>> as data changes, at least for the NFSv4 attribute.
>> 
>> rick
>> 
> Hello Rick,
> 
> I implemented the VFS_SYSCTL work in NFS.  The goal was to allow a path to query filesystems via sysctl.
> 
> This was used in OS X to provide a way to query the filesystem for "events".
> 
> https://github.com/opensource-apple/xnu/blob/10.10/bsd/nfs/nfs_vfsops.c#L5188 <https://github.com/opensource-apple/xnu/blob/10.10/bsd/nfs/nfs_vfsops.c#L5188>;
> 
> For NFS you want to inform the user that an nfs filesystem is down, or the locking daemon is down.  That was inside a GUI you can pop up a dialog box to allow the user to force-unmount or turn off locking.
> 
> Image you're connected to multiple NFS shares inside of X11 or whatever windowing system you have.  Then there is a network outage.  You'll want to know which filesystems are not responding and why.
> 
> -Alfred
> 
> -Alfred

I found a workaround, not elegant, but works,
I added a timeout to the kevent instead of Null.
so now it’s working in busy wait  mode instead of event driven.
I you plant add themishing links, I can heliport with the testing.

thanks,
	danny




help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FCEAD57F-38BC-4CF4-B0CF-7CE0E9571ED1>