From owner-freebsd-fs@freebsd.org  Mon Jan  4 20:08:41 2016
Return-Path: <owner-freebsd-fs@freebsd.org>
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 48216A62257
 for <freebsd-fs@mailman.ysv.freebsd.org>; Mon,  4 Jan 2016 20:08:41 +0000 (UTC)
 (envelope-from sef@kithrup.com)
Received: from kithrup.com (Kithrup.COM [64.142.31.202])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 237BB1DF7
 for <freebsd-fs@freebsd.org>; Mon,  4 Jan 2016 20:08:40 +0000 (UTC)
 (envelope-from sef@kithrup.com)
Received: from kithrup.com (localhost [127.0.0.1])
 by kithrup.com (8.14.4/8.14.4) with ESMTP id u04JxWSN053361
 for <freebsd-fs@freebsd.org>; Mon, 4 Jan 2016 11:59:32 -0800 (PST)
 (envelope-from sef@kithrup.com)
Received: (from sef@localhost)
 by kithrup.com (8.14.4/8.14.4/Submit) id u04JxWGn053360;
 Mon, 4 Jan 2016 11:59:32 -0800 (PST) (envelope-from sef)
Date: Mon, 4 Jan 2016 11:59:32 -0800 (PST)
From: Sean Eric Fagan <sef@Kithrup.COM>
Message-Id: <201601041959.u04JxWGn053360@kithrup.com>
To: freebsd-fs@freebsd.org
Subject: Re: Monitoring FS changes
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs/>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
 <mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jan 2016 20:08:41 -0000

>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.

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-).