From owner-freebsd-fs@freebsd.org Tue Jan 5 10:49:54 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE374A6181B for ; Tue, 5 Jan 2016 10:49:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6253D1322 for ; Tue, 5 Jan 2016 10:49:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u05Ann0C099365 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 5 Jan 2016 12:49:49 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u05Ann0C099365 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u05AnmsV099364; Tue, 5 Jan 2016 12:49:48 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 5 Jan 2016 12:49:48 +0200 From: Konstantin Belousov To: Sean Eric Fagan Cc: freebsd-fs@freebsd.org Subject: Re: Monitoring FS changes Message-ID: <20160105104948.GG3625@kib.kiev.ua> References: <201601041959.u04JxWGn053360@kithrup.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201601041959.u04JxWGn053360@kithrup.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 10:49:55 -0000 On Mon, Jan 04, 2016 at 11:59:32AM -0800, Sean Eric Fagan wrote: > >The generic problem we have there is quite different. Assume that > >we establish a new monitor on a directory, and assume there exists > >previously open file, which vnode should be now monitored by the > >'children' rule. How can we learn that the vnode must be included in the > >watching set, i.e. marked ? Same issue occurs for fhopen() and for NFS > >handles. > > xnu solved that by putting a parent pointer in each vnode (obviously, not set > for non-fs objects). Once they did that, this kept a reference for each > vnode, and voila, always there. The voila part is somewhat problematic. You must ensure the liveness of the reference to the parent vnode, which immediately raises the question of parent vnode being recycled without updating the children pointers. So you must track all children, to not leave stale parent pointers around. This is because vnodes only represent a cache of the on-disk structures. We do have a machinery to track the parent/children relations, it is called the name cache. But it is a cache and can be dropped at any time. This is why e.g. vn_fullpath() or executable names in /proc or lsof output are lost sometime. Anyway, having great ideas does not make this stuff implemented even a bit closer. If anybody with his/her great ideas does not bother even to formulate the wanted API and explicitely document desired behaviour, the thing will never happen. > > They also keep a reference cache of names; this makes a lot more sense on a > Mac OS system since so many directories and files have the same name > (there are 9400 instances of "Info.plist" on my laptop at the moment, for > example). > > The memory footprint for each of these was not too large. But, then, Apple > wasn't supporting systems with less than 1gbytes of ram at the time 8-).