All of lore.kernel.org
 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: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-13 23:02 [RFC 1/2] fanotify: new event FAN_MODIFY_DIR 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
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.