Date: Wed, 6 Jan 1999 21:17:31 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Terry Lambert <tlambert@primenet.com>, dillon@apollo.backplane.com (Matthew Dillon) Cc: dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Message-ID: <199901070517.VAA02732@salsa.gv.tsc.tdk.com> In-Reply-To: Terry Lambert <tlambert@primenet.com> "Re: questions/problems with vm_fault() in Stable" (Jan 7, 3:15am)
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901070517.VAA02732>