Stacked file systems - why not and what instead?
Stacked file systems - why not and what instead?
- Subject: Stacked file systems - why not and what instead?
- From: Ragnar Sundblad <email@hidden>
- Date: Wed, 03 Mar 2004 05:55:59 +0100
Hello all,
First, excuse me for not knowing very much about vfs and asking
maybe trivial questions, I am trying to learn about this stuff.
Apple Q&A 1242 says:
...
Stacking File Systems -- Apple does not support the development
of stacking VFS plug-ins on Mac OS X. We've taken this position
because, in our opinion, it's not possible to create a stacking
VFS plug-in that:
1. works reliably,
2. does not severely impinge on system performance, and
3. has any hope of binary (or even source-level) compatibility
with future systems.
...
If you have a problem that can only be solved via a stacking
file system, please let us know by mailing DTS.
...
Background:
We are depending on the file system AFS in our environment
of different unix flavours. The AFS client is, as I
understand it, very much a stacked file system.
AFS works more or less like many other file systems except
that the client caches files on local disk.
To keep the client caches in sync, the client get callbacks
from the server when the server need to change a file
that the client has cached. (Very simplfied, it also has some
other nice and pretty unique properties that I skip here.)
We have for some years had the privilege of having not just
one but two working AFS clients for mosx, Arla and OpenAFS.
Now with 10.3/darwin 7 both these clients have different
problems. OpenAFS seems to have some general vnode problem
causing the kernel to panic sooner or later typically with
"panic(cpu 0): vnreclaim: v_usecount",
"panic(cpu 0): non UBC vnode on inactive list" or
"panic(cpu 1): vinactive: vnode still on list",
Arla has some other issues.
Arla has a userland daemon that handles the communication
with the servers and a kernel module that does as little
as possible, I think it has many similarities to the webdav
client. OpenAFS does (almost?) everything in the kernel.
Both use file caches on local disk with ordinary files which
live in a special cache directory.
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? (Of course one could use a separate cache
partition with a completely custom file system, but that,
for a novice as me, sounds like much more work and much more
bug prone than using an existing file system for the cache,
so I don't like that idea.)
I'd be happy if someone could explain both of these statements
from Q&A 1242:
"
... it's not possible to create a stacking VFS plug-in that:
1. works reliably,
2. does not severely impinge on system performance
"
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?
Wasn't there some ideas about a cleaner and more static
file system api for darwin?
Thanks for any help or information!
/ragge
_______________________________________________
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.