From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:48787 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751542AbdATJYI (ORCPT ); Fri, 20 Jan 2017 04:24:08 -0500 Date: Fri, 20 Jan 2017 09:47:51 +0100 From: Jan Kara To: Amir Goldstein Cc: lsf-pc@lists.linux-foundation.org, Jan Kara , linux-fsdevel , linux-api@vger.kernel.org Subject: Re: [LSF/MM TOPIC ATTEND] thawing the fsnotify subsyetm Message-ID: <20170120084751.GB14115@quack2.suse.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu 19-01-17 16:28:09, Amir Goldstein wrote: > My employer has a use case of watching file system changes > over millions of directories. > > It so happens that the same product (cloud sync) also runs on > Windows and on MacOS. both OS have a scalable API to monitor > file systems changes over millions of directories. > > Since the product requires being notified on filename events > (e.g. create/delete/rename), the only available option on Linux is > inotify, but inotify does not scale well to millions of directories > use case and not a the right tool for the job in general. > > For that purpose, I implemented fanotify super block watch [1], > to be able to: > 1. report filename events > 2. watch over file system root (as opposed to mount point) > 3. report event information using struct file_handle, > instead of keeping open file descriptor per event Yeah, I think this would be worth a discussion. I've got other requests for similar functionality so Amir is not the only one with the needs. But given how unsuccessful we have been with file change notification API in the past I'm very conservative about its extensions and would prefer to have wider discussion about this. Honza -- Jan Kara SUSE Labs, CR