Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!udel!cis.udel.edu From: pezely@cis.udel.edu (Daniel Pezely) Newsgroups: comp.os.minix Subject: Re: Minix reading/writing non-Minix file systems (SunOS?) Keywords: multiple filesystem daemons Message-ID: <33054@nigel.ee.udel.edu> Date: 10 Oct 90 23:50:59 GMT References: Sender: usenet@ee.udel.edu Reply-To: pezely@udel.edu Followup-To: comp.os.minix Distribution: na Organization: R+D Cowboys, HITL, Seattle & CSL, U of Delaware Lines: 28 Nntp-Posting-Host: pokey.cis.udel.edu In-reply-to: bruner@sp15.csrd.uiuc.edu's message of 10 Oct 90 18:04:12 GMT Originator: pezely@cis.udel.edu >I seem to recall that for testing purposes Berkeley first implemented >the 4.2BSD filesystem under 4.1BSD with user-mode code that wrote to >files. However, my memory of this is pretty hazy. If indeed this is >true, then using that code in application programs might be the >easiest path for reading and writing BSD filesystems. This is what I was thinking of. After all, isn't minix's file system code a system program and not in the kernel? So, how about if there were two file system daemons running? One for normal minix file systems and the second for SunOS. I'll play with having two fs daemons first, and that might increase performance of the system anyway. After all, on a SunOS file server, it is recommended that you run 6 or 7 nsfd programs so that the overall average time of NFS requests handled is improved. Message passing doesn't have to be handled all by one program, but I don't want to get into a discussion about that (yet). I do realize that problems will be encountered and a decrease in performance will arise due to byte ordering and such, but the flexibility of being able to take a drive with you from site to site greatly outweighs all that. -cowboy dan -- R+D Cowboys: HITL, Seattle CSL, U Delaware Pezely@hitl.VRnet.washington.edu Pezely@udel.edu