Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ucsd!sdcsvax!ucsdhub!jack!crash!pnet01!sreeb From: sreeb@pnet01.cts.com (Ed Beers) Newsgroups: comp.sys.atari.st Subject: Re: WARNING: Bug (?) in TurboDOS Message-ID: <2844@crash.cts.com> Date: 19 Apr 88 05:56:19 GMT Sender: news@crash.cts.com Organization: People-Net [pnet01], El Cajon CA Lines: 38 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