root@snowhite.cis.uoguelph.CA (12/17/88)
I agree that it would be a very useful item. I currently have a non-Sun
implementation of NFS Version 2 mostly written, that is intended to go
in a Berkeley Unix kernel arround a vnode layer. {I am just starting the
plug it into the kernel part, and this will take several months..}
If there is someone out there that is a DOS wizard and keen enough to try
to incorporate it into a freely available TCP/IP package, they are more
than welcome to the code. However, it does look like a bit of an onerous
task for several reasons:
- none of the current freely available packages remain resident and I
don't know how easy it is to change them to at least share the net
interface with resident NFS client code?
- I don't know how you catch the DOS BIOS calls on the filesystem?
{ Not being a DOS wiz, my best guess is that you revector the 21H interrupt
and then filter out the requests on the net disks, but...}
- Once you do all this, you must still write code that converts the BIOS
calls into corresponding vnode ops to call the client code I have written.
{ Not to mention, port it to a PC C compiler with 16bit ints }
Any Heroes??romkey@asylum.sf.ca.us (John Romkey) (12/17/88)
Yeah, unfortunately the worst part of an NFS implementation on an IBM PC is writing the redirector, which has to exactly match DOS. You do this either by using misinformation about undocumented hooks into and from DOS or by catching int 21 (DOS system call interrupt; BIOS only handles raw disk accesses, not the filesystem) and exactly emulating DOS including a number of undocumented DOS system calls that nasty programs like, oh, say, Microsoft C perform. Then you have to map non-DOS conformant filenames to something DOS-like (upper case, 8 characters optional . 3 characters). Next to this, I expect the implementation of the NFS protocol itself to be almost a non-issue. - john
root@snowhite.cis.uoguelph.CA (12/18/88)
I know I am going to end up with egg on my face, but here goes... > interesting tidbits. Redistributable as part of a product. Written with a > simple, extensible, slow, and memory intensive attitude, but it can be - therefore, I avoided using the Sun RPC code entirely and built the RPCs directly in mbuf lists (I didn't realize BIOS referred to the driver level interface but not the DOS function calls and as such I was misusing the term, however) suppose you wrote a driver that looked like a vdisk, with a large cluster size and a big FAT table size - then when reads occur on sectors of the root dir. you translate them to NFS readdir and lookup rpc's and fake DOS dir entries with the first cluster numbers faked as values such that each file's clusters are referenced by different sectors of the FAT (1 or 2 sectors should be enough space in the FAT for a file with a big cluster size) - then reads of the FAT sectors can be recognized as such and faked with sequential cluster #'s in it --> reads on the file would become reads on well known sector #'s that could be translated to NFS read rpc's OR some other kludgey scheme that generates a fake FAT table such that the driver knows what part of which file is being accessed when a read/write request is made on sectors of the virtual disk admittedly, subdirectories and writing files such that they grow would be very messy, since you would have to remember the FAT updates and at least the name and fake first cluster # part of all fake directory entries generated. (I am guessing that DOS doesn't cache this stuff and reads the directory file every time a file is opened??) For our institution, even a kludgey read only pc nfs would be useful if it was free.
geoff@eagle_snax.UUCP ( R.H. coast near the top) (12/20/88)
In article <8812170248.AA03407@asylum.sf.ca.us> romkey@asylum.sf.ca.us writes: >Yeah, unfortunately the worst part of an NFS implementation on an IBM >PC is writing the redirector, >[...] >Next to this, I expect the implementation of the NFS protocol itself >to be almost a non-issue. > - john Almost true, but there are still many problems related to the NFS protocol implementation. Things like how and where you cache things to avoid unnecessary network traffic (directory searching is a good example); how you manage 32-byte file handles (you certainly can't store them in the FCB!); and how you map the various error conditions into the DOS error-handling framework (and coping with all those bugs - especially in DOS 3.0 and 4.0). Lots of good(?) stuff to keep engineers busy during the long winter nights... -- Geoff Arnold, Sun Microsystems Inc. +--------------------------------------+ PC Dist. Sys. Group (home of PC-NFS) |When you're fresh out of lawyers, you | UUCP: {hplabs,decwrl...}!sun!garnold |don't know how good it's going to feel| ARPA: garnold@sun.com +--------------------------------------+
bc@halley.UUCP (Bill Crews) (12/20/88)
In article <8812171427.aa05527@Louie.UDEL.EDU> root@snowhite.cis.uoguelph.CA writes: >suppose you wrote a driver that looked like a vdisk, with a large cluster >size and a big FAT table size >[...scheme definition...] If a disk server will do what you need, this is much, MUCH more easily done than implementing an NFS client. I don't know what model to use these days -- probably ND. Then you let DOS manage the FAT for you. If you want a file server, I don't see where fooling with the FAT is going to buy you anything. -bc -- Bill Crews bc@halley.UUCP (512) 244-8350 ..!rutgers!cs.utexas.edu!halley!bc