Date: Tue, 22 Aug 95 12:38:48 MDT From: terry@cs.weber.edu (Terry Lambert) To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: hackers@freebsd.org Subject: Re: Using space in a DOS filesystem Message-ID: <9508221838.AA01109@cs.weber.edu> In-Reply-To: <199508220656.QAA25934@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Aug 22, 95 04:26:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9508221838.AA01109>