From: Jan Kara <jack@suse.cz>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Jan Kara <jack@suse.cz>,
"Sergey \"Shnatsel\" Davidoff" <sergey@elementaryos.org>,
Pavel Machek <pavel@ucw.cz>,
linux-kernel@vger.kernel.org
Subject: Re: A desktop environment[1] kernel wishlist
Date: Tue, 4 Nov 2014 10:28:09 +0100 [thread overview]
Message-ID: <20141104092809.GB2953@quack.suse.cz> (raw)
In-Reply-To: <5457C7B7.7050302@gmx.de>
On Mon 03-11-14 19:21:43, Heinrich Schuchardt wrote:
> On 31.10.2014 10:36, Jan Kara wrote:
> >On Mon 27-10-14 20:02:51, Sergey "Shnatsel" Davidoff wrote:
> >>>If "recursive mtime" was available, would that work for you?
> >>
> >>It would work for detecting "offline" changes. I suppose recursive
> >>mtime not viable for online monitoring, mostly because detecting file
> >>renaming would be a massive PITA (and we already have fanotify with
> >>exactly this problem).
> > Yes, you'll get only "something has changed in a subtree" information for
> >each directory. You'd then have to rescan the directory to find out what
> >has changed. But there's no simple solution for this - either you have to
> >process tons of events for busy directory tree or you have to somehow
> >reduce the amount of information provided to userspace...
>
> If inotify_add_watch() would allow to mark a complete mount (like
> fanotify_mark() called with FAN_MOUNT) events for all files on this
> mount could be detected. If furthermore inotify_read() would return
> the complete relative path of the changed file relative to the mount
> in inotify_event->name, it would be obvious what the meaning of the
> event is.
There are two catches though:
1) Getting of the path itself is unreliable due to presence of other fs
changes happening in parallel to you traversing the directory tree.
2) The name you get from inotify_event->name is unreliable because by the
time you read the event, directory tree may be completely different.
These are the reasons why fanotify passes file descriptors with the
events instead of names.
Also for mountpoint wide notification your app has to be much faster
processing events so that the event queue doesn't overflow (and thus forces
you to do full rescan). fanotify deals with this by not limiting event
queue length at all but that's one of the reason why it's restricted to
CAP_SYS_ADMIN users.
So all in all I would find it better to extend fanotify to provide
directory events (that was originally planned but the support was dropped
due to technical issues), solve problems with unlimited event queues, add
some permission checking for passed file descriptors and audit fanotify to
verify it's otherwise safe for regular users.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2014-11-04 9:28 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-21 8:49 Bastien Nocera
2014-10-21 13:11 ` Sergey
2014-10-22 2:58 ` Minchan Kim
2014-10-22 16:52 ` Dan Streetman
2014-10-22 20:16 ` Heinrich Schuchardt
2014-10-27 16:11 ` Sergey "Shnatsel" Davidoff
2014-10-27 9:23 ` Pavel Machek
2014-10-27 16:02 ` Sergey "Shnatsel" Davidoff
2014-10-31 9:36 ` Jan Kara
2014-11-03 18:21 ` Heinrich Schuchardt
2014-11-04 9:28 ` Jan Kara [this message]
2014-11-04 19:55 ` Heinrich Schuchardt
2014-11-05 17:18 ` Jan Kara
2014-10-21 17:04 ` John Stultz
2014-10-21 17:14 ` Bastien Nocera
2014-10-21 18:00 ` John Stultz
2014-10-21 18:09 ` Bastien Nocera
2014-10-21 19:10 ` John Stultz
2014-10-27 14:19 ` Bastien Nocera
2014-10-27 16:56 ` John Stultz
2014-10-28 22:57 ` One Thousand Gnomes
2014-10-30 14:41 ` Bastien Nocera
2014-10-30 23:39 ` One Thousand Gnomes
2014-10-31 14:03 ` Bastien Nocera
2014-11-03 14:17 ` One Thousand Gnomes
2014-10-30 14:35 ` Bastien Nocera
2014-10-30 23:25 ` One Thousand Gnomes
2014-10-31 14:01 ` Bastien Nocera
2014-11-21 19:08 ` Pavel Machek
2014-10-21 19:23 ` Andy Lutomirski
2014-10-22 17:04 ` Zygo Blaxell
2014-10-27 14:28 ` Bastien Nocera
2014-10-27 20:59 ` Zygo Blaxell
2014-10-28 12:36 ` Bastien Nocera
2014-10-28 14:36 ` John Stultz
2014-10-31 13:54 ` Bastien Nocera
2014-10-31 17:38 ` John Stultz
[not found] ` <CANszf4gaozN9YHzxUToRP9CaA1VVEV9vcz_X6LDL1zW3fH4Fow@mail.gmail.com>
2014-10-28 16:41 ` Fwd: " Rogelio Serrano
2014-10-27 9:28 ` Pavel Machek
2014-10-27 14:31 ` Bastien Nocera
2014-10-28 18:50 ` suspend to partition " Pavel Machek
2014-10-30 13:57 ` Bastien Nocera
2014-10-29 19:19 ` Andy Lutomirski
2014-10-29 20:26 ` Theodore Ts'o
2014-10-29 21:16 ` Pavel Machek
2014-10-30 14:45 ` Bastien Nocera
2014-10-30 14:53 ` Andy Lutomirski
2014-10-30 15:07 ` Bastien Nocera
2014-10-30 18:23 ` Pavel Machek
2014-10-31 13:57 ` Bastien Nocera
2014-10-30 15:05 ` Theodore Ts'o
2014-10-30 15:15 ` Bastien Nocera
2014-10-30 15:34 ` Theodore Ts'o
2014-10-30 15:36 ` Bastien Nocera
2014-10-30 17:41 ` Pavel Machek
2014-10-31 13:59 ` Bastien Nocera
2014-10-30 23:21 ` One Thousand Gnomes
2014-10-30 23:19 ` One Thousand Gnomes
2014-10-30 14:42 ` Bastien Nocera
2014-10-28 22:42 ` One Thousand Gnomes
2014-10-21 18:24 ` Geert Uytterhoeven
2014-10-27 14:20 ` Bastien Nocera
2014-10-27 15:31 ` Geert Uytterhoeven
2014-10-27 15:44 ` Bastien Nocera
2015-04-30 16:25 ` Bastien Nocera
2015-04-30 17:10 ` John Stultz
2015-04-30 17:23 ` Olof Johansson
2015-04-30 18:54 ` Chirantan Ekbote
2015-05-01 9:02 ` Tomeu Vizoso
2015-05-04 22:19 ` Rafael J. Wysocki
2015-05-05 6:05 ` Tomeu Vizoso
2015-05-05 12:31 ` Rafael J. Wysocki
2015-05-07 16:54 ` One Thousand Gnomes
2015-05-07 21:03 ` Rafael J. Wysocki
2015-05-08 7:09 ` Tomeu Vizoso
2015-05-04 22:12 ` Rafael J. Wysocki
2015-05-04 23:30 ` Chirantan Ekbote
2015-05-05 10:46 ` Bastien Nocera
2015-05-05 19:22 ` Chirantan Ekbote
2015-05-06 12:41 ` Bastien Nocera
2015-05-05 14:39 ` Alan Stern
2015-05-05 17:58 ` Chirantan Ekbote
2015-05-05 19:35 ` Alan Stern
2015-05-05 20:58 ` Chirantan Ekbote
2015-05-05 23:56 ` Rafael J. Wysocki
2015-05-05 23:38 ` David Lang
2015-05-05 23:51 ` Rafael J. Wysocki
2015-05-07 17:03 ` One Thousand Gnomes
2015-05-07 18:21 ` Chirantan Ekbote
2015-05-05 23:47 ` Rafael J. Wysocki
2015-05-06 17:40 ` Chirantan Ekbote
2015-05-07 23:19 ` Rafael J. Wysocki
2015-05-11 22:12 ` Pavel Machek
2015-05-12 0:45 ` Rafael J. Wysocki
2014-10-21 19:28 ` Andy Lutomirski
2014-10-21 19:43 ` Al Viro
2014-10-21 19:47 ` Andy Lutomirski
2014-10-27 13:55 ` Bastien Nocera
2014-10-27 15:12 ` Andy Lutomirski
2014-10-27 15:45 ` Bastien Nocera
2014-10-27 16:08 ` Andy Lutomirski
2014-10-27 16:09 ` Bastien Nocera
2014-10-27 16:22 ` Al Viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141104092809.GB2953@quack.suse.cz \
--to=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=sergey@elementaryos.org \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®