7103_2622@uwovax.uwo.ca (Eric Smith) (05/21/91)
Is there a nice way to tell TOS (version 1.4 and higher) *not* to cache a drive? I want to share a drive over a network; clients will see the drive as read-only, but I'd like the server to be able to write to the drive. The only problem is that if the clients are caching FAT and directory info, there could be problems when/if this gets changed. Has anyone ran into this problem before? If so, what did you do about it? -- Eric R. Smith email: Dept. of Mathematics eric.smith@uwo.ca University of Western Ontario 7103_2622@uwovax.bitnet
danny@fiction.ms.sub.org (DanielRoedding) (05/25/91)
7103_2622@uwovax.uwo.ca (Eric Smith) writes: > Is there a nice way to tell TOS (version 1.4 and higher) *not* to > cache a drive? I want to share a drive over a network; clients > will see the drive as read-only, but I'd like the server to be able to > write to the drive. Since you have to write a little device driver, you also have to take care of the media change state. If you return 2 all the time at Mediach() calls, TOS should not keep old information it it's caches. BTW: Do you address the drive on file or on block level? If you write some- thing that intercepts the trap #1 vector, you don't have to do anything like this, since *you*'ll get all calls first... Daniel
apratt@atari.UUCP (Allan Pratt) (05/29/91)
danny@fiction.ms.sub.org (DanielRoedding) writes: >7103_2622@uwovax.uwo.ca (Eric Smith) writes: >> Is there a nice way to tell TOS (version 1.4 and higher) *not* to >> cache a drive? I want to share a drive over a network; clients >> will see the drive as read-only, but I'd like the server to be able to >> write to the drive. >Since you have to write a little device driver, you also have to take care >of the media change state. If you return 2 all the time at Mediach() calls, >TOS should not keep old information it it's caches. If you return 2 on every call, then you could never do anything: 2 means HAS CHANGED, and all open handles on the drive are closed. Subsequent accesses with those handles would return EIHNDL (invalid handle). Even if you return 1 and find that GEMDOS always re-reads the sectors, this will be REALLY SLOW, because TOS uses Mediach() to validate its cache buffers, and it happens A LOT in some cases. Example: for each Fsfirst/Fsnext call in a directory search, you'll get at least one Mediach() call. If you actually had to read the sector over the net for each call, it would be unbelievably slow. I don't know a way to cache a drive from outside. You're better off using MetaDOS to catch the calls at the filesystem level rather than the BIOS level. If a call is destined for a remote filesystem you make it a remote procedure call at the top level, not the record level. Eric, aren't you running MiNT? You already have the capability: just mount it like you do a Minix filesystem and make remote procedure calls at that level. You could even do local caching and make remote calls like, "Are my cached buffers still valid?" to reduce your net traffic. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
7103_2622@uwovax.uwo.ca (Eric Smith) (05/30/91)
In article <2951@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes: > danny@fiction.ms.sub.org (DanielRoedding) writes: >>7103_2622@uwovax.uwo.ca (Eric Smith) writes: >>> Is there a nice way to tell TOS (version 1.4 and higher) *not* to >>> cache a drive? I want to share a drive over a network; clients >>> will see the drive as read-only, but I'd like the server to be able to >>> write to the drive. > >>Since you have to write a little device driver, you also have to take care >>of the media change state. If you return 2 all the time at Mediach() calls, >>TOS should not keep old information it it's caches. > > If you return 2 on every call, then you could never do anything: 2 means > HAS CHANGED, and all open handles on the drive are closed. Subsequent > accesses with those handles would return EIHNDL (invalid handle). > Yeah, that's what I was afraid of. > Eric, aren't you running MiNT? You already have the capability: just mount > it like you do a Minix filesystem and make remote procedure calls at that > level. You could even do local caching and make remote calls like, "Are > my cached buffers still valid?" to reduce your net traffic. > The file server is running MiNT, but I didn't want to require the client to be -- I was just going to write a little TSR that hooks into Rwabs to do the networking. Oh well, looks like I'll have to break down and add networking to MiNT after all :-). Thanks to both of you for your answers. -- Eric R. Smith email: Dept. of Mathematics eric.smith@uwo.ca University of Western Ontario 7103_2622@uwovax.bitnet