🚀 go-pugleaf

exodus@uop.edu (G.Onufer) writes:
>
>Well, as much as I love the performance of TurboDOS, I will not use it
>until one matter is straightened out.  I just added the original Tandem
>drive from my SH204 to the Micropolis drive I had replaced it with.  Now
>both are merrily storing all the data I give to them off of the SH204
>controller board.  So I thought I would do some timings of TurboDOS/non-Turbo-
>DOS.  I copied the TeX sources from SCSI-1/LUN0/PARTf to SCSI-1/LUN1/PARTc
>(actually f: to g:) and timed em.  Took 2:34 sec with Beckemeyer's HD accel,
>took 2:06 sec with TurboDOS.  Except fsck tells me it's okay the long way and
>that there is a free clustor smack in the middle of a file the fast way.
>(oh...those should be MINUTES times, not seconds :-)
>
>So, is this a problem with having two drives on one controller?  Depending
>on how much TurboDOS assumes about the hardware configuration, it may scrap
>the LUN number in its caching.  Time to actually go through the code and
>start replacing addresses with labels and adding comments.......Ughhh.
>
>Also, I would not recommend using any disk repair utilities that directly
>access the drives while using Turbodos.  May really screw things up if and when
>Turbodos flushes its buffers.
>
>Allen:  Any way to force a program such as TurboDOS to flush it's buffers?
>Write a desk acc to do it?   (Add symbolic links to the next TOS!!)
>
>G. Onufer

I am a little suspicious of fsck and its companion optimizer.  I had a hard
disk partion that fsck and chkdsk ( using pc-ditto ) both liked.   I used the
optimizer after which: fsck was still happy.  all my files were still
accessable from gem.  pc-ditto could no longer see several of my directories.
chkdsk attempted to repair the disk and appeared to be success full.  fsck was
no longer happy and i had about 2 meg of file which took up space but were
invisable from gem.  I zapped the partion, restored all the files and haven't
had any problems since.

UUCP: {cbosgd hplabs!hp-sdd sdcsvax nosc}!crash!pnet01!sreeb
ARPA: crash!pnet01!sreeb@nosc.mil
INET: sreeb@pnet01.cts.com