Date: Mon, 21 Aug 95 18:25:08 MDT From: terry@cs.weber.edu (Terry Lambert) To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: bde@zeta.org.au, roberto@keltia.frmug.fr.net, freebsd-hackers@FreeBSD.org Subject: Re: Install issues (was: State of the union speech Message-ID: <9508220025.AA27824@cs.weber.edu> In-Reply-To: <199508220001.JAA25059@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Aug 22, 95 09:31:21 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Oddly, I haven't had any bites on my last post about this, so I'll ask > again : I have code that creates a large contiguous slab of sectors in > an MSDOS filesystem, and hides them under a file. I've explored > what I can of the diskslice code and the like, but I'm at a loss as to > how to redirect a slice to point at this slab, short of rewriting > the partition table (which would be Bad) or writing a variant on the > vnode driver (which would defeat the whole purpose). > > 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? I have several issues which aren't addressed right now, so I was reluctant to be the first to respond. 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. 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. The vnode pager is not really what we want to deal with. Windows 95 actually got this (mostly) right, though they screwed up when they put knowledge of partition types into the TSD's (type specific drivers: they have specific knowledge of the FS when they should only have specific knowledge of the partition ID's). What they do is provide a physical device and logical devices which point to a physical device and have a "partition bias". They screwed up again here, since the MS supplied TSD's don't return the partition bias field filled out. 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 actually strikes at the heart of what I think is wrong with the current disklabel code. The PowerPC under a PReP/OpenFirmware implementation assumes a DOS partitioning scheme, but uses the sector offset field rather than the C/H/S field -- 4GB worth of 512 byte sectors, or 2TB of disk. They look for the AA55 signature, and if it isn't present, they assume that the physical device constitutes a single partition. This is their way around the need for a DOS partition on all devices, though PPC AIX puts one on their boot floppies anyway (IBM PPC 40P + AIX). I think the logical drive allocation by type specific driver to get a logical physical device per partition, then further take logical physical drives into pure logical drives by either disklabel or by logical drive implemented on logical physical drives is the correct general soloution to this problem. It means the ability to translate a physical device into one or more logical physical devices, which are then translated into pure logical devices and mounted by a file system based on their identification of the drive as one they want (for UFS, this is by the UFS magic number in the superblock). This is actually what Win95 does with a stacked drive: It uses the physical device, runs a TSD to decode the partitions if it sees a partition table, and take the logical drives after that. It then mounts the logical drive under VFAT, and the stacker FSD (file system driver) looks on drives for the stacker file and exports that as a logical device of type "stacker", which it then mounts. What we want is a logical device of type "FreeBSD". I don't know who currently "owns" the diskslice code, but since this would mean another set of revisions if we wanted to access the contiguously allocated sectors in any file system as a device (rather than translating the address into file block offsets and eating the performance hit that would result), I think it bears more than casual scrutiny before any changes can be made. 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.). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9508220025.AA27824>