louboutn@ccvax.ucd.ie (07/24/90)
> In his book, Andrew Tanenbaum suggests that it should not be too > complicated to implement a remote file server under Minix. I would be > very interrested to hear from people having actually implemented a > system where, for instance, (hard)diskless PCs running Minix use > the services of a common file server. > > Please, e-mail to me, I will summarize. As the volume of answers I received is not very large, I will just post them (with permission): --Sylvain -------------------------------------------------------------------------------- As a Master's thesis at North Dakota State University, Jeff Hernes implimented a crude remote file server. Since Jeff had no network, everything ran on the same machine. It didn't really work that well, either. Another student, Tim Kachel, developed a simple contention bus for Minix systems, using serial ports. If anyone is interested in either of these people's work, you may contact me at the following address, or his advisor, Dr. Robert Gammill at NDSU Computer Science Department. It is my understanding that all of their work is in the Public Domain, but is based on (now) old versions of Minix. >I am currently using Minix 1.3; Is this question totally obviated >by more recent versions ? no, not really. We now have the Amoeba networking, but no remote filesystems or Network Disks. -- Glen Overby <overby@plains.nodak.edu> uunet!plains!overby (UUCP) overby@plains (Bitnet -------------------------------------------------------------------------------- I have done something like this. I implemented remote devices. I added an extra parameter to devices so that they had a major, minor and system number. A /dev/dh?? for a disk on a remote system could then made the disk mounteted and accessed like a local one. I haven't goten as far tidying it up for release though. If a few people are interested in it I will try to do that over the nest month or two. Let me know about what other replies you get. Tony McGregor ( rdt134f@monu6.cc.monash.edu.au ) Department of Robotics and Digital Tech., Monash University PO Box 197, Caulfield East, Vic 3145, Australia Phone: +61 3 5732014 Fax: +61 3 5732748 -------------------------------------------------------------------------------- Some 2 years back, in the fall of 1988, I implemented a distributed Minix system based on Minix 1.2 in a graduation project. The computers I had to use, were IBM PS/2 Model 60s. There was one central computer with all Minix processes, including the FS. There were up to 3 satellite computers which connected to the central computer via serial RS232c links, on which all Minix processes could run EXCEPT the FS! The satellite computers use the central FS, so they could use the hard disk at the central computer. Because there's only one FS, there's also only ONE file tree. When a satellite mounts a floppy, ram or hard disk, ALL the computers will see it and it's up to the standard Minix file protection mechanisms to hide your local floppy, for instance. Because of the 115200 baud serial link, performance is not good. With ethernet, performance could increase drastically. There are also some problems with the one-file-system-view, because you have only one /tmp for 4 computers, but the system is quite flexible. The tasks on the different computers were assigned different, but fixed major device numbers. So you could `cat' a file on one satellite computer to the tty on another computer (if you have write permission on /dev/ttyxx). I have not implemented it fully. In the final version, no user processes ran on the satellite computers (except for MM and init). This was mainly because the serial network presented some specific problems (deadlock), that showed up when running user processes and that could not be easily fixed. When using ethernet, I guess that you should be able to start user processes on satellite computers. When you're interested, I can give you more details on how it works and how I solved the problems of sending messages transparently over a network. My thesis was in dutch, so it's no good to you. Adrie Koolen, Philips Innovation Center Aachen E-mail: adrie@ica.philips.nl --------------------------------------------------------------------------------