From owner-freebsd-hackers Mon Aug 21 23:12:39 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA05871 for hackers-outgoing; Mon, 21 Aug 1995 23:12:39 -0700 Received: from genesis (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id XAA05862 for ; Mon, 21 Aug 1995 23:12:33 -0700 Received: from msmith@localhost by genesis (8.6.9/8.6.9) id QAA25888; Tue, 22 Aug 1995 16:17:45 +0930 From: Michael Smith Message-Id: <199508220647.QAA25888@genesis> Subject: Using space in a DOS filesystem To: terry@cs.weber.edu (Terry Lambert) Date: Tue, 22 Aug 1995 16:16:29 +0930 (CST) Cc: hackers@freebsd.org In-Reply-To: <9508220025.AA27824@cs.weber.edu> from "Terry Lambert" at Aug 21, 95 06:25:08 pm Content-Type: text Content-Length: 2556 Sender: hackers-owner@freebsd.org Precedence: bulk Terry Lambert stands accused of saying: > > This is basically a ready-to-go partition, it just needs water, so to speak. > > I'm interested in seeing this code; where do I go to get it? ftp://genesis.atrad.adelaide.edu.au/incoming/mkslab.c > The main one I have is that my DOS partition on the machine I could do > any testing on has been running Win95 for several months. The defragger > un DOS 6.x and above is the Norton defragger, and I haven't been too > anxious to find out how they mark the clusters in the Windows swap file > on Win95 so that the defragger doesn't try to relocate them. Probably > the same way Windows 3.11 and the Norton code works. AFAIK, the file is marked system/readonly/hidden, and thus won't be touched by most defraggers. I used the same approach with the FREEBSD.IMG file. > As it is, I have blocks that can't be modes all over the disk, and > without some type of knowledge here, I couldn't defrag the disk and get > a large contiguous area, which seems to be needed. For testing, 1M is all you need to verify that it works. > The vnode pager is not really what we want to deal with. Capiche; I should have been clearer - I meant vn driver, a la vn0... > What we are interested in is a sector offset and length on the physical > device being exported as a device to the /dev namespace. This is different > from the vnconfig stuff (which is also useful) in that it means you don't > go through a file system to get at the device, so you don't suffer the > problems that a UMSDOS partition would face in terms of block size, etc. This is spot on; however for it to be useful, it has to happen in the kernel at startup, rather than later on in a userspace utility. > As things currently sit, I wouldn't want to go off half-cocked on yet > another diskslice code revision to get "slab" device support, and I > wouldn't want any design to neglect the current diskslice and install > issues that haven't been addressed (logical DOS partitions, immutable > bit so Windows doesn't "defrag" the file", verifying contiguity, etc.). Relevant, relevant, relevant. Any comments on "safety" issues are most welcome. > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[