[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Added inotify support.

From: Nix
Subject: Re: [PATCH] Added inotify support.
Date: Sat, 06 Oct 2012 22:28:49 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

On 6 Oct 2012, Stefan Monnier uttered the following:

>>> If nfsd applies a modification and it's not reflected with some inotify
>>> event, I think that's a bug that the kernel developers would want to fix.
>> They don't care. If an event doesn't come through the normal VFS layers,
>> inotify won't see it, and that's that.
> But that's a bug in nfsd, still.

Well, yes, I think so, and you think so, but the Linux kernel hackers do
not think so :(
from userspace via the VFS: other activity might

>> Oh yes, indeed. I'm just arguing against ripping out polling and
>> replacing it with inotify, really:
> I have no intention to rip out polling.  Rather I hope that the
> higher-level API we come up with can be implemented by any of Windows's
> low-level API, inotify, MacOSX's equvalent, or polling.

... which is what I hoped to hear. I've seen several projects rip out
polling because inotify can do anything, and end up with something that
worked worse for NFS users than what they had before. (NFSv4 could in
theory implement something like inotify, but for earlier versions,
polling is really all you could hope to do. Well, that or have some
parallel daemon inotifying on the clients and informing the server of
inotify activity, and vice versa...)

NULL && (void)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]