Date: Fri, 26 Jul 1996 00:24:03 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: freebsd-fs@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Subject: Union mounts and other mounts Message-ID: <Pine.SV4.3.93.960726001248.1143A-100000@parkplace.cet.co.jp> In-Reply-To: <199606251931.MAA00496@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry, are you out there? Please upload your mega patches. I'm sure someone will take a look and maybe we can at least start with getting the locks fixed. Or do we just have to dream about the possibilities? I want to mount my home source directory on top of a FreeBSD CD and compile as if the CD were writable. I want to start working on a non-itar restricted crypto-fs layer. I want to see a gzip layer. I want to see a mirroring layer mounted on top of a FFS and a EXT2 filesystem. . . . Mike Hancock On Tue, 25 Jun 1996, Terry Lambert wrote: > This is the intrinsic "union" option. > > It does not work. > > It does not work because VOP_ADVLOCK does not veto. > > It does not work because VOP_LOCK can not be stacked because it is > stupidly referencing flags specific to the underlying vnode for lock > resoloution instead of the union vnode. > > It does not work because VOP_LOOKUP, VOP_RENAME, etc. can not > be stacked because they actually deallocate path structures that > were allocated by code in vfs_syscalls.c, instead of the buffers > being deallocated in vfs_syscalls.c as well, as you would expect > in a proper idempotent layering implementation. > > VOP_LOCK stupidly references these flags because vclean needs them. > > vclean is an abomination before God, and is a half-kludge to deal > with not having both vnode/offset and dev/offset based cache > references simultaneously. > > Use of vnode/offset cache entries is a result of the unified cache > implementation. It saves a bmap call when moving data to/from > user space. It's why FreeBSD has faster I/O than most other systems. > > The lack of a parallel dev/offset based caching allows us to be lazy, > and enlarges the bit limit on FS storage, though it does not help > the inherent limit on file size (due to mapping). > > The lack of a parallel dev/offset results in the need for > implementation of a "second chance cache" via ihash. Still, we > will discard perfectly good pages from cache as a side effect of > having no way to reassociate them with a vnode. > > The use of a global vnode pool instead of per FS mount instance vnode > allocations damages cache locality. Combined with vclean, it also > damages cache coherency. > > > To repair: > > 1) Fix the stackability issues with the VFS interface itself, > which will incidently cause the VFS to more closely conform > to the Heidemann Thesis design on which it is based. Currently > it only implements a subset of the specified functionality. > > 2) Migrate the vnode locking to the vnode instead of the per FS > inode; get rid of the second chance cache at the same time > (the Lite2 code does some of this). The pointer should have > been in the vnode, not the inode, from the very beginning. > > 3) Move the directory name cache out of the per FS code and > into the lookup code. > > 4) Move the vnodes from the global pool; establish a per-FS > vnode free routine. > > 5) Establish VOP_GETPAGE/VOP_PUTPAGE, etc... > > 6) Union mounts will then work without kludges in lookup, locking, > and other code. They *could* be made to work with great, gross > kludges and changes to at least 3 FS's (that I know of), but > that's a kludge I won't do. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.960726001248.1143A-100000>