Date: Mon, 21 Aug 95 21:20:03 MDT From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.org, roberto@keltia.frmug.fr.net Subject: Re: Install issues (was: State of the union speech Message-ID: <9508220320.AA28296@cs.weber.edu> In-Reply-To: <199508220233.MAA19187@godzilla.zeta.org.au> from "Bruce Evans" at Aug 22, 95 12:33:06 pm
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 > > I'm not too keen on this, because of coherency issues (what happens if > the file is deleted while it is in use as a partition or after pointers > to it are set up) and lack of generality (it would be better to optimize > the vn driver for contiguous files; it should be possible to avoid going > through the file system except for initialization). Clearly, file locking should be implemented at the vncalls layer above the VFS, only calling the VOP_ADVLOCK() to notify the lower level file system in case it wants to impose its own semantics over and above those enforced by default advisory locking, or if it wants to package up the requests and send them remote. Secondly, there needs to be the concept of mandatory file locking at the same level -- not smeared through each of the VFS FS implementations. This is a design error in the current implementation of advisory locking in the UFS nad other file system modules, and in the kernel code in the file kern/vfs_syscalls.c. 8-). That way, no matter what the underlying file system, you can assure the slab consumer that no hybrid access will take place. The definition of "hybrid" in this case refers to the fact that such a file exists on a hosted basis. There are two consumers of the file system services: the device driver making the file appear as a device, and the normal file system users using the file system itself as a mountd file system instance. A similar situation would be a Samba server exporting a file system to DOS users, a DOS user asserting a mandatory byte range lock on a file, and a UNIX user going in and manipulating the file without honoring the mandatory lock. This is "promiscuous" behaviour, since the interfaces are not identical, The UNIX user fails to honor the DOS locking semantics because he does not access the file system through an interface capable of enforcement. > >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). > > To test it you could create a slice inside the DOS slice containing the > file. I think fdisk allows bogus things like that. Not recommended. I agree. This is totally bogus. The way to handle it is to provide a device to BSD using another mechanism, rather than trying to twist the existing partition mechanism that BSD already knows about into doing the work for you. See my other post. > >This is basically a ready-to-go partition, it just needs water, so to speak. > > The vn driver method already has water :-). Try your file that hides > the sectors as a vn device. It can't hurt to have the sectors contiguous > and performance might be reasonable. I don't think it would be - msdosfs > performance is abysmal and revision 1.16 of vn.c seems to have introduced > doing read/write through the file system except for paging. Yes; unless you divorce the file system from the area of disk it manages and manage it as just another logical device, you are going to have terrible performance penalties. Probably your pseudo-device needs to: 1) Look up the file 2) Assert a mandatory file lock 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 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. 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?9508220320.AA28296>