From owner-freebsd-hackers Tue Jan 9 20:40:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA05781 for hackers-outgoing; Tue, 9 Jan 1996 20:40:08 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id UAA05734 for ; Tue, 9 Jan 1996 20:39:44 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id OAA07751; Wed, 10 Jan 1996 14:10:39 +1030 From: Michael Smith Message-Id: <199601100340.OAA07751@genesis.atrad.adelaide.edu.au> Subject: Re: Add new slice to running system, comments? To: bde@zeta.org.au (Bruce Evans) Date: Wed, 10 Jan 1996 14:10:38 +1030 (CST) Cc: bde@zeta.org.au, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG, phk@critter.tfs.com In-Reply-To: <199601091331.AAA22987@godzilla.zeta.org.au> from "Bruce Evans" at Jan 10, 96 00:31:41 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG Precedence: bulk Bruce Evans stands accused of saying: > > >In this context, vn devices are barely a bandaid. ... > After reading the code :-), I think the vn devices already have decent > performance for the contiguous && swapping case. There isn't much > overhead except for a VOP_BMAP() call for each block. VOP_READ() and > VOP_WRITE() aren't used for the swapping case (they would be extremely > slow for msdosfs and merely OK for ufs). The original vn driver avoided > VOP_READ() and VOP_WRITE() in all cases, but John rewrote it. > Contiguous files are necessary so that the disk doesn't have to seek for > between virtually adjacent blocks. A large block size may also be > necessary. Hmm. Now I'm a little confused 8) Are you saying that the vn device maps the on-disk location of the file (its block map, I presume) and keeps this internally to avoid using the fs-specific read/write functions? If this is the case, then I take everything back and will concentrate solely on using it 8) > Try it and see :-). There's nothing to stop overlapping slices except > fdisks that refuse to create them. Other OS's might by confused by > overlapping slices in the MBR. I was only talking about adding the slices into the in-core table, not to the MBR; I wanted to pretend that the 386spart.par file was really a disk slice so that I could swap on it. > Use vn devices and fix the vm (?) problems that required non-swapping accesses > to go through the file system. I'm not sure how to handle booting from one > of these slices. You could put the slice in the MBR only if there is a free > entry. I'm not sure either; that's something to worry about later 8) > Bruce -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[