Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752367AbdCNOt2 (ORCPT ); Tue, 14 Mar 2017 10:49:28 -0400 Received: from 1.multihost.cz ([88.86.107.244]:34833 "EHLO multihost.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751279AbdCNOsx (ORCPT ); Tue, 14 Mar 2017 10:48:53 -0400 Date: Tue, 14 Mar 2017 15:48:46 +0100 From: Filip =?utf-8?B?xaB0xJtkcm9uc2vDvQ==?= To: Amir Goldstein Cc: linux-fsdevel , linux-kernel , Jan Kara , Alexander Viro Subject: Re: [RFC 1/2] fanotify: new event FAN_MODIFY_DIR Message-ID: <20170314144846.hlrcuwroeopnbna5@rgvaio> References: <20170314124152.w53wga4abqpfml7v@rgvaio> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170128 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1737 Lines: 40 Hi, On Tue, Mar 14, 2017 at 03:55:19PM +0200, Amir Goldstein wrote: > Please let me know if that is sufficient for your needs > or if you need me to prepare a version that delivers filename events > without filename info, therefore allowing to merge filename events. > > Sounds to me like if you get an event FAN_DELETE, "aaa", > your implementation can update the db directly without having > to scan the directory, so it should be useful. > For your consideration. both approaches might be useful and there are tradeoffs. Direct updates save us from rescanning but give more events and more context switches. On the other hand, with an unlimited queue and well-mergable events I could e.g. sleep for five seconds each time after emptying the queue, thus giving the events more potential to merge and reducing context switches. But one risks blowing up the queue. However, I have some ideas. Basically we could implement some kind of "bulk read" mode for fanotify that would pass events to userspace only when (a) a given event count thresold is hit (e.g. half the queue limit if queue is limited), or (b) the oldest event is older than a specified maximum latency. That might vary from 1 second to 5 minutes depending on specific application needs (e.g. background backup does not need to be low-latency). This would greatly reduce extra context switches when watching a large portion (or whole) of the file system. All of this presumably could be implemented on top of your suggested patches. Either way, I suggest that implementing the nameless filename events is a good idea. I do not know whether they will be the best choice for my application but they probably will be useful for some applications. Filip