From owner-freebsd-hackers Tue Aug 22 11:40:11 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id LAA09241 for hackers-outgoing; Tue, 22 Aug 1995 11:40:11 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id LAA09235 for ; Tue, 22 Aug 1995 11:40:09 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA01109; Tue, 22 Aug 95 12:38:49 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508221838.AA01109@cs.weber.edu> Subject: Re: Using space in a DOS filesystem To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Tue, 22 Aug 95 12:38:48 MDT Cc: hackers@freebsd.org In-Reply-To: <199508220656.QAA25934@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Aug 22, 95 04:26:25 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@freebsd.org Precedence: bulk > Terry Lambert stands accused of saying: > > Probably your pseudo-device needs to: > > > > 1) Look up the file > > 2) Assert a mandatory file lock > > Instructions on this one would be needed 8) Open it O_EXCL in the device node exporting code. > > 3) Verify that the file is in fact contiguous > > 4) Export as device node that is an alias for the device node > > the file system is actually on, with the addition of a sector > > bias and a length (both derived from the underlying file system). > > > > This could probably be rolled into vnconfig, but implies a logical to > > Not for the desired purpose, see my recent posts on this thread. It still could. You'd have to boot to an MFS first, which would up by 3M the kernel size, but you could do it. > > physical address translation is possible (you might have to add one > > as a file system specific ioctl()), and a contiguity check is also > > possible (perhaps by traversing the block offsets linearly by using > > an additional "offset" argument to the ioctl() above, or with the > > addition of another ioctl()). Then you'd flag the vnconfig'ed device > > for physical rather than logical I/O. > > Checking for contiguity is relatively trivial given the nature of the > FAT filesystem; all this sort of 'health checking' can be easily > included in the "do we accept this slab" tests. I think you missed my point: There needs to be a file system independent way of checking contiguity in order to make the same shortcut possible on HPFS and NTFS (to name two). Or ext2fs, to name three. 8-). > The issues that I can't resolve at this point are : > > 1) Keeping everyone else's grubby mitts off the file. > 2) Exporting a device/devices that represent the filesystem(s) inside > the slab. Ah. The device exporting code is the rub. We need a generic device registration mechanism. Though I keep yelling "devfs", which would imply that some mechanism like that existed, really the mechanism can exist before the devfs to export the device nodes from the exported devices list (cdevsw/bdevsw) into a file system namespace. Though I think that's the most trivial part of a devfs to implement. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.