kqueue of a nfs mounted file not working

[Daniel Braniss]

> On 18 Nov 2015, at 11:49, Daniel Braniss <danny at cs.huji.ac.il> wrote:
> 
>> 
>> On 17 Nov 2015, at 04:05, Alfred Perlstein <alfred at freebsd.org <mailto:alfred at 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 at 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> <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.
> 
I hate spell checkers
	s/themishing/the missing links/
	s/heliport/help out/

> thanks,
> 	danny
> 
> 
> _______________________________________________
> freebsd-hackers at freebsd.org <mailto:freebsd-hackers at freebsd.org> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org <mailto:freebsd-hackers-unsubscribe at freebsd.org>"