Date: Tue, 22 Aug 1995 16:16:29 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: terry@cs.weber.edu (Terry Lambert) Cc: hackers@freebsd.org Subject: Using space in a DOS filesystem Message-ID: <199508220647.QAA25888@genesis> In-Reply-To: <9508220025.AA27824@cs.weber.edu> from "Terry Lambert" at Aug 21, 95 06:25:08 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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! [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508220647.QAA25888>