From owner-freebsd-hackers Wed Jan 6 21:18:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA04743 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 21:18:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA04738 for ; Wed, 6 Jan 1999 21:18:34 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id VAA28211; Wed, 6 Jan 1999 21:17:34 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id VAA25498; Wed, 6 Jan 1999 21:17:32 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id VAA02732; Wed, 6 Jan 1999 21:17:31 -0800 (PST) From: Don Lewis Message-Id: <199901070517.VAA02732@salsa.gv.tsc.tdk.com> Date: Wed, 6 Jan 1999 21:17:31 -0800 In-Reply-To: Terry Lambert "Re: questions/problems with vm_fault() in Stable" (Jan 7, 3:15am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , dillon@apollo.backplane.com (Matthew Dillon) Subject: Re: questions/problems with vm_fault() in Stable Cc: dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jan 7, 3:15am, Terry Lambert wrote: } Subject: Re: questions/problems with vm_fault() in Stable } You could implement these things rather trivially as it is, if the } bottom end VFS was a variable granularity block store instead of a } "file system" that managed its blocks directly, with the caveat that } stacking something that managed block layout on anything other than } a variable granularity block store layer would be pretty darn useless, } since it would never invoke an inferior VOP that implemented policy. } } Of course, you're aiming at your foot if you do this. Consider an FS } that implements ACL's via a VOP_ACL, and manages its own block layout, } and then stack something like FFS (that *doesn't* implement a VOP_ACL) } on top of that. Now call a system call that calls VOP_ACL, and watch } it spam your FFS contents under you, as it acts unexpectedly. I think it only makes sense to stack something like FFS on top of a file, which could either be a block device or just a plain file in some other filesystem. This would allow you mount a file directly and dispense with /dev/vn* and vnconfig. mount -t ufs /a/filesystem/lives/in/this/file /it/is/mounted/here FFS would allocate blocks from .../this/file and use them to store its inodes, the contents of the file in the filesystem, and so on. The filesystem that contains .../this/file would be responsible for allocating space within that filesystem to store .../this/file. You might want to enhance FFS to deallocate blocks that it doesn't need, which would have no effect if the underlying storage was a block device, but it could be used to make .../this/file sparse (but then you'd have to handle the situation where you couldn't allocate a block because the filesystem that is storing .../this/file is full). This scheme could be nested arbitrarily deeply. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message