From owner-freebsd-fs Thu Jul 25 08:29:35 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA05586 for fs-outgoing; Thu, 25 Jul 1996 08:29:35 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA05477; Thu, 25 Jul 1996 08:28:19 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id PAA01422; Thu, 25 Jul 1996 15:24:03 GMT Date: Fri, 26 Jul 1996 00:24:03 +0900 (JST) From: Michael Hancock To: freebsd-fs@FreeBSD.ORG cc: freebsd-hackers@FreeBSD.ORG Subject: Union mounts and other mounts In-Reply-To: <199606251931.MAA00496@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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. >