Date: Wed, 12 Jul 2000 10:14:52 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Kelly Yancey <kbyanc@posi.net> Cc: Marius Bendiksen <mbendiks@eunet.no>, Dmitry Brodsky <dima@cs.ubc.ca>, freebsd-fs@FreeBSD.ORG Subject: Re: Meta-Data & stackable FS Message-ID: <Pine.NEB.3.96L.1000712100201.50110C-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0007112346510.39799-100000@gateway.posi.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 12 Jul 2000, Kelly Yancey wrote: > So long as you only stack over FFS. As much as I like the idea of > extended attributes, stacked file systems should be able to stack over > any other filesystem. Unless I'm mistaken, NFS doesn't support EA's, not > to mention any of the misc. filesystems. I don't even know where one > would begin trying to add EA support to say, procfs. On the other hand, it's not clear that this stacking over arbitrary file systems is possible due to differences between file systems in the first place -- as nice as VFS may be, in its current incarnation it doesn't address cache coherency and event issues, numerous different semantics, etc. A growing number of file systems will be supporting EAs, currently including UFS/FFS, XFS, HPFS, and patches are available for ext2fs, although I don't believe they have been ported to FreeBSD. It would be relatively easy, although perhaps not all that useful, to add EA support to procfs, given that there are no persistence requirements beyond the lifetime of the in-kernel process structure. And with a file system like procfs, there is currently no machinery for procfs to notify layers above it of changes in its structure, if stacking were the mechanism of choice. > But the man page touches on this, and other valid converns: > > As there are a plethora of file systems with differing extended > attributes, availability and functionality of these functions may be > limited, and they should be used with awareness of the underlying > semantics of the supporting file system. Authorization schemes for > extended attribute data may also vary by file system, as well as > maximum attribute size, and whether or not any or specific new > attributes may be defined. > > How could you possibly build a stackable filesystem using EA's when there > are so many unknowns except for the degenerate case of "you can stack this > filesystem over FFS, or you can't stack it anywhere". > > And that doesn't even touch the fact that even with FFS, other filesystems > can trample on EA's required by your filesystem. The ideas behind EA's are > noble, but I can't see using EA's in practice. :( I think the real-world answer, and the reason I opted to implement EAs, is that stacking is not a feasible solution for exactly the same reasons: the infrastructure is (at best) flakey, the semantics are poorly defined, key functionality is missing for cache coherency and event handling (especially if you stack over NFS or other weak-consistency file systems), and without some sort of transactional (using the term loosely) event agregation across layers, it's not even clear that the result can be reliable in failure situations. I don't see any of that being fixed soon. EAs have relatively well-defined semantics, although some fs-specific limitations with well-defined failure modes, and are supported by a wide (and increasing) variety of file systems. In any case, assuming that a working and sufficiently strong stacking environment exists (FiST satisfies a number of these requirements, I believe), the chances are you'd add the service (say, ACLs) by layering EA's on top of FFS, and then a service on top of EA+FFS, in which case you'd be relying on vnode operations introduced by the EA layer, and presumably they would strongly resemble the EA VOP's already present, and probably should even be the same VOPs :-). In which case EA+FFS is indistinguishable from FFS w/EAs. 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.1000712100201.50110C-100000>