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 | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.