On Sat, May 30, 2020 at 03:34:06PM +0200, Martin Pieuchot wrote: > On 30/05/20(Sat) 09:22, Visa Hankala wrote: > > On Thu, May 28, 2020 at 12:11:20PM +0200, Martin Pieuchot wrote: > > > When it comes to kqueue filters NFS is special. A custom thread is > > > created when the first event is registered. Its purpose is to poll > > > for changes every 2.5sec. This logic has been inherited from NetBSD > > > and is not present in FreeBSD. > > > > > > Since filt_nfsread() only check `n_size' of a given nfsnode having a > > > different context to emulate stat(2) behavior in kernel is questionable. > > > So the diff below gets rid of this logic. The rationals are KISS, > > > coherency with nfs_poll() and match what other FS kqueue filters do. > > > > > > While here add a missing write filter. > > > > > > Matching the nfs_poll() logic and the write filter are necessary to keep > > > the current behavior of poll(2) & select(2) once they start querying > > > kqfilter handlers. > > > > I think it is not good to remove nfs_kqpoll(). The function does more > > than just supports the read filter. It generates various vnode events. > > If the poller is removed, it becomes impossible for example to monitor > > an NFS directory with kevent(2). > > What do you mean with "impossible to monitor a NFS directory"? Are you > saying that NFS being is the only FS to have a specific thread to implement > a poller is wanted feature? If it is wanted, why is it NFS only? Which > use case involve monitoring a NFS directory with kevent(2)? When are we > aware of the existence of a "nfskqpoll" kernel thread?
Local filesystems can observe changes at the source, which makes polling unnecessary. NFS clients do not have that benefit. The NFSv3 protocol lacks a mechanism to notify clients of changes. The NFS polling mechanism is in use for example when running tail -f on a remote file. Directory monitoring can be utilized for example by a directory browser application or a distributed batch processing system. > > It is true that the code is not perfect, but having even basic and > > best-effort functionality with kevent(2) and NFS is better than nothing > > in my opinion. The kqueue subsystem should not dumb down for emulating > > poll(2) and select(2). > > In that case we've to accept or work-around with the fact that a thread > is allocated, an operation that can fail, in the kqfilter(). Do you have > an opinion on that? What should we do for other FSs is uniformity wanted? Can't the emulation of poll(2) and select(2) operate without the poller? These system calls are supposed to return true for regular files for reading and writing. No polling of remote state is needed for that. The read behaviour of poll(2) and select(2) differs from kevent(2)'s EVFILT_READ. Consequently, there has to be an indicator that makes f_event work in poll(2)/select(2) mode. I guess the same indicator can control nfs_kqfilter().
