Re: Stacked file systems - why not and what instead?
Re: Stacked file systems - why not and what instead?
- Subject: Re: Stacked file systems - why not and what instead?
- From: Quinn <email@hidden>
- Date: Wed, 3 Mar 2004 15:57:51 +0000
At 5:55 +0100 3/3/04, Ragnar Sundblad wrote:
Apple Q&A 1242 says:
Marek did a fine job of answering your questions but, seeing as I
wrote the Q&A in question, I feel obliged to follow up with more
information.
My questions:
Could this be implemented at all without using a stacked
file system, and what would be the apple recommended way
of doing it?
Yes, implement it the way WebDAV works. This isn't a full blown
stacked file system, but it does palm a lot of the work off to the
actual file system that holds the cache.
... it's not possible to create a stacking VFS plug-in that:
1. works reliably,
Darwin inherited a VFS design from 4.4BSD that included stacking.
However, Apple made significant changes to the VFS architecture
(specifically, UBC and volfs) that affect the viability of stacking.
I believe that these changes break stacking in the general case, and
no one in Apple file system engineering has the resources to create
an example stacked file system that proves me wrong.
btw For information about volfs, see DTS Q&A 1113 "The '/.vol'
directory and 'volfs'".
<
http://developer.apple.com/qa/qa2001/qa1113.html>
Regardless of the in-kernel problems there are also serious
management problems for stacked file systems. Off the top of my head
I can think of the following.
o How do you get stacked on top of all mounted volumes? The disk
mounting process on Mac OS X is managed by Disk Arbitration, which
has no support for stacking.
o Imagine you're writing a compression stacked file system. How do
you ensure that your file system is stacked above any encrypting file
systems? [Compressing after encryption is pointless.]
In some cases you can work around these issues by constraining the
design or UI of your stacked file system, but that's not true in the
general case.
2. does not severely impinge on system performance
Marek explained the vnode problem in his response. This isn't an
issue for a prototype system (just increase the size of the vnode
pool), but it is a problem if Apple was to support stacking as a
general purpose solution for a consumer OS like Mac OS X. Imagine if
the user had 4 file systems stacked on top of each vnode (not
implausible: file system notification, anti-virus, compression,
encryption). Suddenly the vnode pool is 20% smaller than it should
be. Even if it was acceptable to gobble that much wired memory,
managing the growth of the vnode pool is tricky without global
knowledge of what stacked file systems are installed and what vnodes
they are using.
The problem with the 4.4BSD stacking architecture IMHO is that it
uses one solution (stacking vnodes) to cover a spectrum of problems.
Not all stacked file systems need a full vnode at their layer. For
example, an anti-virus stacked file system just wants to intercept
file system opens; it doesn't need its own copy of the file data
(which is what the vnode represents). OTOH, an encrypting stacked
file system would probably benefit from having a vnode at its level
(the stacked vnode holds the decrypted UBC data while the underlying
vnode holds the encrypted UBC data). Unfortunately, our current
architecture doesn't support this distinction.
And regarding this one:
"
3. has any hope of binary (or even source-level) compatibility
with future systems.
"
Would a stacking file system have (significantly) more
compatibility problems than a non stacking file system?
You're right, a stacked file system is not substantially less binary
compatible than a non-stacked file system (although that could change
in the future). They both have serious release-to-release
compatibility problems. However, we chose to support leaf file
systems for the following reasons.
o More developers work on leaf file systems than on stacked file systems.
o Leaf file systems are more important to our market than stacked file systems.
o There are up-to-date, production-quality leaf file systems in
Darwin. You you can use these as sample code. This isn't true for
stacked file systems. In fact, I know of no up-to-date,
production-quality open source stacked file system for Mac OS X.
o When we do have a kernel binary compatibility story (see below), it
will likely address leaf file systems as a priority. This is because
Apple has internal leaf file systems that we have to port to it.
Stacked file systems may be supported by these interfaces, or may not
be, depending on the availability of engineering resources.
Wasn't there some ideas about a cleaner and more static file system
api for darwin?
We introduced the concept of Kernel Programming Interfaces (KPI) at
WWDC 2003. This introduction was more of a architecture sketch than
a detailed specification. Since then we've been working hard to
flesh out the KPI story for VFS plug-ins and NKEs. I'm hoping that
we'll cover this in depth at WWDC 2004. However, the session details
haven't been made public yet so I can't commit to anything at this
time. If you're interested in hearing the latest news about KPIs,
keep an eye on the WWDC web site. The session details should be
published soon.
<
http://developer.apple.com/wwdc/>
If you wish to be notified of WWDC-related topics, you should
subscribe to ADC News.
<
http://developer.apple.com/devnews/index.html>
* * *
Finally, I'd like to reiterate the comments I made in the Q&A. The
fact that Apple doesn't encourage or support stacking doesn't mean
that you can't do it. It just means that a) you can't get official
support from DTS, and b) you will probably suffer more binary
compatibility problems than if you were developing a supported
product. However, we have no secrets--the entire kernel source is
available via Darwin--and there's a variety of unofficial support
resources (such as this list). Marek is even using this technology
in a commercial product and he hasn't (yet) been abducted by the
Apple Kernel Purity Police (tm) (-:
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.