Subject: Re: fileassoc (Re: CVS commit: src)
To: Elad Efrat <>
From: Bill Studenmund <>
List: tech-kern
Date: 07/17/2006 19:22:37
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Sorry if this is a duplicate, but it seems my first response didn't go=20

On Mon, Jul 17, 2006 at 10:03:38PM +0200, Elad Efrat wrote:
> Bill Studenmund wrote:
> > Why? That's the best level for this. Only the file system really knows=
> > what's going on. So it's the best place to put the hooks.
> >=20
> > Note: to be clear, I think it'd be best if the fileassoc call that says=
> > "file is gone" comes from the fs itself as opposed to above it.
> first - i'm not sure why the current hook in sys_unlink() is not okay.

For two big reasons. For the first, let me quote yamt:

> let's define "file was removed" first.
>         1. whenever link count is decremented.
>         2. when link count reaches 0.  ie. disappeared from namespace.
>         3. when the last reference is closed after #2.
>         4. other?
>    =20
> i think #3 is reasonable, and if so, sys_unlink is not a right place.

Putting the hook in sys_unlink() is option #1, which I agree isn't really=
what we want.

We want notifications on #2 and #3. Well, we want #2 if we play games=20
based on path name; when a #2 removal happens, we need to remove a given=20
path name from our db.

We need to do #3 for things that keep state based on file ID, like=20
veriexec and such.

My second big issue with the hook in sys_unlink() is what happens if the=20
remove operation fails? Say I am not root (and veriexec is off), but I "rm=
/bin/sh". I then generate fileassoc_file_delete() calls.

A secondary concern is that all callers of VOP_REMOVE() will have to add=20
this logic. We do not heavily document what callers of the different VOPs=
need to do, other than locking. Adding things like this will either need=20
documentation or will become error-prone.

The file system knows when the operation will succeed yet hasn't happened.=
It also knows best when cases #2 and #3 happen. So I think calls in the fs=
are the best thing to do.

> then, i'd like us to have the ability to let stuff hook into such
> events. why not?

Oh! I LOVE the idea of hooking into these events! I just think we need the=
hook in the fs, not above it.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)