From owner-freebsd-fs@freebsd.org Tue Jan 5 05:33:53 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 13F03A61FA5 for ; Tue, 5 Jan 2016 05:33:53 +0000 (UTC) (envelope-from jordanhubbard@icloud.com) Received: from pv33p03im-asmtp002.me.com (pv33p03im-asmtp002.me.com [17.143.180.11]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EDC7112A0 for ; Tue, 5 Jan 2016 05:33:52 +0000 (UTC) (envelope-from jordanhubbard@icloud.com) Received: from [10.11.111.236] (50-250-239-90-static.hfc.comcastbusiness.net [50.250.239.90]) by pv33p03im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O0G001GYSS7EL50@pv33p03im-asmtp002.me.com> for freebsd-fs@freebsd.org; Tue, 05 Jan 2016 05:33:45 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-01-04_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1601050106 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Monitoring FS changes From: Jordan Hubbard In-reply-to: <20160105034327.B650FB827@mail.bitblocks.com> Date: Mon, 04 Jan 2016 21:33:43 -0800 Cc: freebsd-fs@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <1CAAFE08-D24E-49AA-8EC5-4397A199DA3E@icloud.com> References: <201601041959.u04JxWGn053360@kithrup.com> <416747176.149128068.1451960539354.JavaMail.zimbra@uoguelph.ca> <20160105034327.B650FB827@mail.bitblocks.com> To: Bakul Shah X-Mailer: Apple Mail (2.3112) 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 05:33:53 -0000 > On Jan 4, 2016, at 7:43 PM, Bakul Shah wrote: >=20 > Why not do this (at least at first) in a user mode program? > Intercept FS system calls and write relevant info to a user > program's memory. You still need to add a syscall to watch > files/dirs for various events and to validate requests. This > will allow you to experiment with various implementations > before commiting to a complicated new mechanism in the kernel. That=E2=80=99s basically how FSEvents work. There=E2=80=99s a fairly = straight-forward (Mach IPC based) kernel upcall mechanism for = communicating the filesystem change events (and control inputs for what = to watch) to a daemon, fseventsd, and it=E2=80=99s the userland daemon = which subscribers talk to and it figures out how many events to cache, = when all subscribers have received the events (or timed out) and it can = re-use the memory, and so on. The kernel reporting mechanism can be relatively light-weight if you = proxy all the subscription and memory management details through a = userland daemon, which is why I certainly wouldn=E2=80=99t suggest doing = it any other way=E2=80=A6 - Jordan