Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Nov 2015 11:59:09 +0200
From:      Daniel Braniss <danny@cs.huji.ac.il>
To:        Alfred Perlstein <alfred@freebsd.org>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, Rick Macklem <rmacklem@uoguelph.ca>, hackers@freebsd.org
Subject:   Re: kqueue of a nfs mounted file not working
Message-ID:  <DEAA67D5-05B5-4358-893F-B3598D604BAF@cs.huji.ac.il>
In-Reply-To: <FCEAD57F-38BC-4CF4-B0CF-7CE0E9571ED1@cs.huji.ac.il>
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> <FCEAD57F-38BC-4CF4-B0CF-7CE0E9571ED1@cs.huji.ac.il>

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

> On 18 Nov 2015, at 11:49, Daniel Braniss <danny@cs.huji.ac.il> wrote:
>=20
>>=20
>> On 17 Nov 2015, at 04:05, Alfred Perlstein <alfred@freebsd.org =
<mailto:alfred@freebsd.org>> wrote:
>>=20
>>=20
>>=20
>> 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:
>>>>>=20
>>>>> 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.
>>>>=20
>>> 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.
>>>=20
>>> 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?
>>>=20
>>> 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.
>>>=20
>>> rick
>>>=20
>> Hello Rick,
>>=20
>> I implemented the VFS_SYSCTL work in NFS.  The goal was to allow a =
path to query filesystems via sysctl.
>>=20
>> This was used in OS X to provide a way to query the filesystem for =
"events".
>>=20
>> =
https://github.com/opensource-apple/xnu/blob/10.10/bsd/nfs/nfs_vfsops.c#L5=
188 =
<https://github.com/opensource-apple/xnu/blob/10.10/bsd/nfs/nfs_vfsops.c#L=
5188> =
<https://github.com/opensource-apple/xnu/blob/10.10/bsd/nfs/nfs_vfsops.c#L=
5188 =
<https://github.com/opensource-apple/xnu/blob/10.10/bsd/nfs/nfs_vfsops.c#L=
5188>>
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> -Alfred
>>=20
>> -Alfred
>=20
> I found a workaround, not elegant, but works,
> I added a timeout to the kevent instead of Null.
> so now it=92s working in busy wait  mode instead of event driven.
> I you plant add themishing links, I can heliport with the testing.
>=20
I hate spell checkers
	s/themishing/the missing links/
	s/heliport/help out/

> thanks,
> 	danny
>=20
>=20
> _______________________________________________
> freebsd-hackers@freebsd.org <mailto:freebsd-hackers@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@freebsd.org =
<mailto:freebsd-hackers-unsubscribe@freebsd.org>"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DEAA67D5-05B5-4358-893F-B3598D604BAF>