Subject: Re: metahook(9)
To: Brett Lymn <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 06/19/2006 09:36:36
Content-Type: text/plain; charset=us-ascii
On Sat, Jun 17, 2006 at 09:02:53PM +0930, Brett Lymn wrote:
> On Thu, Jun 15, 2006 at 11:08:20AM -0700, Bill Studenmund wrote:
> > You also are using identifiers (dev_t and inode_t) that really shouldn'=
> > be used outside of the file system. We have cleaned-up abstraction=20
> > structures (file handles, for example) that remove much of the problem=
> > wiht what you're doing. Their existence predates my use of NetBSD, and=
> > actually they predate NetBSD. Yet you aren't using them.
> The blame for the usage of dev_t and inode_t can be laid at my feet.
> When I started working on veriexec I looked for something that would
> uniquely identify the file and found the va_fileid and va_fsid
> elements in struct vattr. Though they may be referenced as dev_t and
> inode_t in the veriexec code they really are not used as anything
> apart from tags to uniquely identify a file on a file system. These
> values are taken from the results of a VOP_GETATTR() call and are only
> compared with results of other VOP_GETATTR() calls. So, though the
> numbers may have meanings in other contexts, in the context of
> veriexec they are just a tuple of numbers to identify the file.
> Unless I am mistaken, I believe that the metahook code is treating
> dev_t and inode_t in the same manner - just as unique tags.
Well there are issues. One is that unionfs doesn't use them right; you=20
just get the inode number from the underlying file, be it the upper or=20
lower. :-( So two files can return the same inode number.
> > Plus, generation numbers are important, even for local disk stores. Sin=
> > you aren't storing pointers to the vnodes, use file handles.
> Any hints on using file handles? I had a quick look around an the
> only thing I could see was fhopen() and friends who use VOP_VPTOFH().
> According to the man page for VOP_VPTOFH() it only works on NFS
> exportable file systems. Won't this preclude some file systems?
> Including NFS? (since NFS mounts cannot be re-exported, indeed the
> nfs_vptofh() and nfs_fhtovp() calls return EINVAL).
We probably should fix this for NFS. The calls are TRIVIAL. The one issue=
might be that our file handles may not hold the other system's file=20
handle, but things will at least work for some systems.
While you shouldn't export NFS client mounts, I don't think VFS_VPTOFS()=20
is the place to force that.
Actually, the man page I have for VFS_VPTOFH doesn't restrict it to NFS=20
exports. I think the constraint is that NFS-exportable file systems MUST=20
support FH<->VP operations, but that other, non exportable, file systems=20
may also support them.
The biggest issue I see with file handles is that they are variable=20
length. For the hashing Elad had in mind, that's not a big deal. For=20
storage, it might be. I'm not sure what the best way to approach this is.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----