vfs05.patch
This is what is tentitively going in tomorrow (thursday). It looks
like a can of worms but half of it is stuff to glue the old and new
interfaces together so I can convert things piecemeal, then I get to
scrape all the glue off and hopefully have a work of art :-). In
fact, this first patch only moves [f]chdir(), [l]stat(), and the mount
code over to the new interface.
fetch http://leaf.dragonflybsd.org/~dillon/vfs05.patch
Basically, for those people interested, the old BSD API worked like
this:
[setup path] -> namei -> elm -> VOP_LOOKUP -> [side effects] -> vfs_cache
|
V
cache coherency
[implemented per vfs basis]
[all sorts of locked vnodes directory vnodes, etc] -> VOP_*() ->
[weird side effects]
And the new API works like this:
[setup path] -> nlookup -> vfs_cache -> [miss] -> VOP_RESOLVE ->
| [just fills in a
V passed namecache
high level cache coherency structure, no other
policy hooks side effects].
[fewer locked namecache structures] -> VOP_*() -> [no side effects]
That is, the new interface does all the path handling in the kernel
without touching the VFS, and only talks to the VFS when it needs to
resolve a file/dir name that it doesn't have a namecache record for.
And then instead of passing all sorts of weird combinations of vnodes
and directory vnodes and cnp's (componentname structures) in a multitude
of lock/not-locked configurations the new interface simply passes
namecache records to those other VOPs that deal with namespace operations
(e.g. stat, remove, create, rename) and the VFS code can pull out
whatever vnodes it needs from the namecache records.
Seems simple enough, except the old API has all sorts of interdependancies
between VOP_LOOKUP() and VOP_REMOVE/RENAME/CREATE which the new much
simplified VOP_RESOLVE interface isn't supposed to handle, so all of that
junk has to be moved into VOP_REMOVE/RENAME/CREATE for each VFS in the
system, and *that* is a lot of work.
But the grand result, when all is said and done, is going to be a big
improvement in path lookup performance (at least 2x), much less vnode
lock contention, a caching layer that resides entirely in a high
level kernel layer that we can then implement a separately managed cache
coherency policy for, no kernel requirement to hold directory vnodes
locked through namespace operations (though most VFS's will still do
that themselves until they can be fixed), and a hugely simplified
VFS API which will it a lot easier to write new filesystems and, of
course, make it easier for us to implement a user process messaging
API to run VFS's in userspace.
--
So, prepare for a bit of instability the next few weeks! The worst
should be over in ~3 weeks. If you want your DragonFly to remain
totally stable then stick with the "DragonFly_Stable" tag instead of head.
If you want to test the VFS work as it goes in, stick with head.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)