Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752642AbdCNNqx (ORCPT ); Tue, 14 Mar 2017 09:46:53 -0400 Received: from 1.multihost.cz ([88.86.107.244]:33264 "EHLO multihost.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751680AbdCNNqs (ORCPT ); Tue, 14 Mar 2017 09:46:48 -0400 Date: Tue, 14 Mar 2017 14:46:41 +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: <20170314133819.twemzksniu3uowam@rgvaio> References: <20170313231624.uhqwehzihqnakked@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: 1699 Lines: 42 Hi, On Tue, Mar 14, 2017 at 12:40:56PM +0200, Amir Goldstein wrote: > An I am very happy that you used filehandles to keep track of objects > in your example, because it fits my proposal really well. you can read more about the rationales in the WIP draft of my thesis (especially the chapter Identifying Inodes and its surroundings): http://regnarg.cz/tmp/thesis.pdf https://github.com/regnarg/bc Either way, one can never use pathnames as identifiers because in a world with parallel renames on multiple levels of the hierarchy (between which no ordering is guaranteed unless they are cross-dir), pathnames are not even a well-defined concept. NB: I used a simple script for testing that does precisely this (a lot of parallel within-directory renames at many levels): https://github.com/regnarg/bc/blob/master/experiments/fanotify/parallel_renamist.sh It seems like a good stress test for any application that tries to do reliable filesystem monitoring. > See, if you used my proposed API, you would have had > > fan_fd = CHK(fanotify_init(FAN_UNLIMITED_QUEUE| \ > FAN_EVENT_INFO_PARENT | FAN_EVENT_INFO_FH, > O_RDONLY)); Sure, I'll definitely try to implement your interface as an optional backend and mention it in my thesis and definitely give it some heavy testing. > Furthermore, my proposal records the filehandle at the time of the event > and therefore, does not have to keep an elevated refcount of the object > in the events queue. That sounds good but from what I've understood, not all filesystems support handles. Is this a concern? (Maybe the right answer is to extend handle support...) Filip