[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 19:51:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

On 6 Oct 2012, Stefan Monnier stated:

>>> - can we reliably determine whether it will work?
>> No :( you get that subset of events that happened on the local machine
>> only, but even I ran Emacs on the server, it would see a local
>> filesystem but would *still* miss events -- those happening on the
>> desktop.
> That's a misfeature that should be easy to fix (in the kernel): any FS
> should be able to indicate whether it will reliably send
> inotify notices, so that client code can be told when it requests
> inotify events for a particular object whether it will work reliably.

Unfortunately not, because e.g. a perfectly normal local ext4 filesystem
can be unreliable if it is NFS-exported -- worse, it can be *partially*
unreliable if only a subtree is exported, and it can flip between
reliable and potentially unreliable on the fly as you export or unexport

>>> IIUC inotify works reliably for local file-systems (even if they're
>>> exported because the other hosts's actions will be locally performed
>>> by the nfsd)
>> Those don't always appear :( the nfsd doesn't do all its actions at a
>> level that inotify can see, alas,
> 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.

>>> Can inotify inform Emacs that its notices won't be reliable (so Emacs
>>> can decide to use polling instead)?
>> I don't think so. The answer in any case is 'inotify is never reliable':
>> even if the FS is not exported across the network and never becomes
>> exportted across the network, the queue can fill up and lose events and
>> the like.
> Can't that be fixed by making it possible to "compress" the queue,
> e.g. replace a bunch of events on FILE with a single "something happened
> to FILE", or in the worst case replace all the events with a single
> "queue filled up, all the files might have been modified in arbitrary
> ways".

Theoretically, yes, only that would require you to look at previously
queued events, which soon gets you into locking horrors. (As a first
approximation, *anything* to do with the filesystem soon gets you into
locking horrors.)

> This would let it be reliable even in the face of lost events.
>>> Aren't they used by most GUI file managers?
>> Yes. If you have an NFS-mounted home directory, you get used to hitting
>> refresh in GUI file managers :(
> So there's nothing for Emacs to worry about, because Emacs won't fix
> those issues.

Oh yes, indeed. I'm just arguing against ripping out polling and
replacing it with inotify, really: we need at least a customization knob
for people who know their filesystems are NFS-exported or otherwise
network-affected to tweak to say 'poll, please'.

NULL && (void)

reply via email to

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