Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Jul 2000 13:48:30 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        Dmitry Brodsky <dima@cs.ubc.ca>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: Meta-Data & stackable FS
Message-ID:  <Pine.NEB.3.96L.1000711134206.35768G-100000@fledge.watson.org>
In-Reply-To: <200007102330.QAA06084@cascade.cs.ubc.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 Jul 2000, Dmitry Brodsky wrote:

> I am in the process of creating a stackable fs by using the nullfs as
> a template.  One thing I am having a hard time figuring out is a good
> way to instantiate additional meta-data with each file.  Is that 
> possible?  What is the best way of going about doing that?

If this is non-persistent meta-data, you can store it off of the vnode in
your layer via v_data.  However, if it's persistent, you'll need to store
it elsewhere, and have a way to map the persistent data back onto the
vnodes in future instantiations.  For some stacked file systems I've
looked at, persistent storage of layering data is done via a
transformation on the underlying vnode.  In others, namespace escapes are
used to provide storage.

Both of these techniques have substantial limitations for per-file
attribute data (such as ACLs).  In the TrustedBSD framework, we've
introduced two additional VOP's to get and set extended attributes on
files, and support exists in UFS/FFS to back extended attributes.  Stacked
file systems sitting on top of UFS can store meta-data for a vnode under
the layer in EA's off of that vnode.  This addresses maintaining a
correspondence between the meta-data and nodes, as the namespace quirks of
UNIX (hard links, et al) and page/block alignment memory mapping
requirements make the other methods at best uncomfortable. 

One thing to keep in mind with stacked file systems and the UFS attribute
mechanism is that locking is a substantial concern: as not all locks can
be acquired in advance in the current framework, it's easy to get into
deadlock situations.

There are also a couple of bugs in the EA support in 5.0, including some
refcount issues on the vnodes.  Kirk has simple fixes for that, and may
already have committed them.  In essence, vrele's are missing from some of
the syscall wrappers, resulting in vnode leaking.

  Robert N M Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000711134206.35768G-100000>