mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Filip Štědronský" <r.lkml@regnarg.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Jan Kara <jack@suse.cz>, Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [RFC 1/2] fanotify: new event FAN_MODIFY_DIR
Date: Tue, 14 Mar 2017 13:41:52 +0100	[thread overview]
Message-ID: <20170314124152.w53wga4abqpfml7v@rgvaio> (raw)
In-Reply-To: <CAOQ4uxi3kyPnwfhFe2qDAsLsWjoX2uftgY1KfMCTUZ5p6ferBA@mail.gmail.com>

Hi,

On Tue, Mar 14, 2017 at 12:11:40PM +0200, Amir Goldstein wrote:
> >   - file system indexers / desktop search tools
> >   - file synchronization tools (like Dropbox, Nextcloud, etc.),
> >     online backup tools
> 
> This last one is the use case of my employer, Ctera Networks.
> Out of curiosity, what is the use case that you are focusing on?

I'm working on a file synchronization tool as part of my bachelor
thesis at Charles University.

When I started (now over a year ago ... long story), there were AFIK no
attempts at solving the recursive inotify issue, only a lot of
complaints, so I cobbled up together something simple (I'm not a kernel
developer by trade, this was my first patch) that would allow me to
work on the userspace parts, which are the main bulk.

I try to focus on algorithmic and implementation efficiency as opposed
to fancy GUIs and similar. I want it to be fast with 100k directories
and 10M files in home dir. But it's very WIP so we'll see how that turns
out.

> I had the feeling that all recursive inotify users are hiding in the shadows,
> but was missing more concrete evidence.

Yes, even Dropbox uses inotify. They have articles in their help on how
to increase inotify.max_user_watches: https://www.dropbox.com/help/145.
That's not good PR. ;-) (I'm not affiliated with DB, just pointing that
out.)

> About the argument of not having to change in-kernel framework,
> I don't think it should be a consideration at all.

Understood. I tried to stay conservative and non-controversial because I
imagined that radical framework changes would take months of discussions
(look at the history of statx) and this issue seems to be pressing for
quite a lot of people.  But rushing is of course not the best strategy
either, there are always compromises.

> If you don't specify FAN_EVENT_INFO_NAME, you can get filename events
> FAN_MOVE|FAN_CREATE|FAN_DELETE without the name.
> 
> What you do get is the file descriptor of the parent. sounds familiar? ;-)

I didn't notice this bit. That sounds like a win-win.

Filip

  reply	other threads:[~2017-03-14 12:41 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-13 23:02 Filip Štědronský
2017-03-13 23:03 ` [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes Filip Štědronský
2017-03-14 11:18   ` Amir Goldstein
2017-03-14 14:58     ` Filip Štědronský
2017-03-14 15:35       ` Amir Goldstein
2017-03-15  8:19       ` Marko Rauhamaa
2017-03-15 13:39         ` Jan Kara
2017-03-15 14:18           ` Marko Rauhamaa
2017-03-15 14:44           ` Amir Goldstein
2017-03-19 10:19     ` Jan Kara
2017-03-19 10:37       ` Filip Štědronský
2017-03-19 18:04         ` Jan Kara
2017-03-20 11:40           ` Amir Goldstein
2017-03-20 11:52           ` Filip Štědronský
2017-03-21 15:38       ` J. Bruce Fields
2017-03-21 16:41         ` Jan Kara
2017-03-21 17:45           ` J. Bruce Fields
2017-03-13 23:16 ` [RFC 1/2] fanotify: new event FAN_MODIFY_DIR Filip Štědronský
2017-03-14 10:40   ` Amir Goldstein
2017-03-14 13:46     ` Filip Štědronský
2017-03-14 15:07       ` Amir Goldstein
2017-03-20 12:10       ` Amir Goldstein
2017-03-14 10:11 ` Amir Goldstein
2017-03-14 12:41   ` Filip Štědronský [this message]
2017-03-14 13:55     ` Amir Goldstein
2017-03-14 14:48       ` Filip Štědronský
2017-03-14 22:30         ` Amir Goldstein
2017-03-15 14:05   ` Jan Kara
2017-03-15 14:34     ` Amir Goldstein
2017-03-16 10:38       ` Jan Kara
2017-03-15  4:52 ` Michael Kerrisk

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=20170314124152.w53wga4abqpfml7v@rgvaio \
    --to=r.lkml@regnarg.cz \
    --cc=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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®