Date: Sat, 27 May 2000 01:36:10 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Zhihui Zhang <zzhang@cs.binghamton.edu> Cc: Chuck McCrobie <mccrobi@aplcenMP.apl.jhu.edu>, freebsd-fs@FreeBSD.ORG Subject: Re: Opinion on File System Implementation Message-ID: <Pine.NEB.3.96L.1000527012918.40564D-100000@fledge.watson.org> In-Reply-To: <Pine.SOL.4.21.0005261045410.5111-100000@sol.cs.binghamton.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 26 May 2000, Zhihui Zhang wrote: > On Fri, 26 May 2000, Robert Watson wrote: > > > In 5.0-CURRENT, I introduced rudimentary support for extended attributes > > in UFS/FFS to support security extensions I have been working on, so we > > also pushed in simple command line tools to allow userland to > > read/set/control extended attributes (setextattr(8), getextattr(8), > > extattrctl(8)). It may be that this interface is the appropriate > > interface to read, if not write, this meta-data. > > > > I am interested in where you are going to put those extended attributes, > in the extended inode, in the file data, or in a separate associated file? Currently, the attributes are backed to normal files treated as indexed arrays under UFS. I.e., very similar to the quota implementation--a userland process invokes extattrctl() to inform the kernel of mappings between particular named attributes and particular backing files. I posted a relatively detailed description of this to freebsd-fs/freebsd-arch a few months ago before committing, you may want to check the archive for full details. In the long term, an alternative solution needs to be found--right now, from the perspective of softupdates/et al, these attributes are considered "data" not "meta-data", so in the event of a crash, there are few guarantees about consistency and event ordering. Unlike quotas, you can't just inspect the file system to see what the correct values are. I have some safety checks to determine if an extended attribute is appropriate for the inode it's mapped against based on the generation number, which catches use of the file system prior to the mapping being configured, and most results of fsck. In the long term, presumably the correct answer is to make use of some HPFS-like mechanism, although I like to make a distinction between extended attributes (FreeBSD, HPFS, ...) and file forks (NTFS, HFS, ...), where extended attributes have fairly stringent semantics and a limited API (get, replace, remove), vs. a complete address space supporting its own file descriptor, mmap, etc. Switching to an alternative mechanism would also improve performance, especially if the file system/store maintained spacial locality for attributes and inodes they are assigned to. Needless to say, there are lots of design choices in this arena--I posted an overview of common choices for backing ACLs in various UNIX-esque file systems last year at some point. I can repost if desired. The current mechanism is sufficient to support the TrustedBSD labeling requirements during development, which was the goal. :-) 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.1000527012918.40564D-100000>