gert@nikhefh.hep.nl (Gert Poletiek) (04/14/88)
In article <8804131634.AA17900@ucbvax.Berkeley.EDU> WALDI@DHDIHEP1.BITNET writes: > >Hello! I tried TURBODOS (downloaded from UH-INFO). Really impressing >speed-up, BUT: It spoilt a disk. Apparently it did not recognize >a disk change, and copied the old disk's FAT to the changed new disk. >The disks have different serial numbers, and I did never have this problem >with TOS-GEMDOS, although I'm aware it might happen under certain circum- >stances there. Has anyone similar experiences with TURBODOS? >----------------- Roland Waldi It becomes more and more clear that TURBO-DOS is not a disk caching program but a real file system. I it is very likely that the French guys that did this TurboDos took a disassembly of the original TOS/GemDos as a guidance. If all of this is true, then TurboDos is as vulnerable to disk change events as the original GemDos. However, DISK CHANGE EVENTS ARE HANDLED BY THE BIOS, and the old GemDos has problems with these too. BUT, the old GemDos does practically do no disk caching whatsoever (you can't call two disk sectors a cache, can you?). There is a provision in GemDos for a disk cache mechanism, although in the old GemDos this does not work correctly (i.e., the cached blocks are invalidated every once in a while causing the cache to do noo harm to your disk, it just eats memory). If TurboDos has fixed these problems it may be even more dangerous than the original GemDos. GemDos' provision for disk caching is NOT A WRITE THROUGH CACHE, but like the UNIX buffer cache A DELAYED WRITE CACHE. This is very dangerous if you do not have a system call like 'sync' on UNIX. What happens when say 20 blocks are in the buffer cache when you decide to eject the floppy by hardware (your thumb)?? You'll get the problems described by Ronald Waldi. Solution: IFFF TurboDos works a bit like our local hack on GemDos (called JamDos) then you might avoid the described problem by quitting from the current application (too bad if that's the DeskTop, there's no way out of that), since the original GemDos would then flush all cached buffers to the the disks. Gert Poletiek NIKHEF-H, Dutch National Institute for Nuclear and High Energy Physics Kruislaan 409, P.O.Box 41882, 1009 DB Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!nikhefh!gert bitnet: nikhefh!gert@mcvax.bitnet, U00025@hasara5.bitnet
wolf@csclea.ncsu.edu (Thomas Wolf) (04/15/88)
In article <451@nikhefh.hep.nl> gert@nikhefh.hep.nl (Gert Poletiek) writes: >In article <8804131634.AA17900@ucbvax.Berkeley.EDU> WALDI@DHDIHEP1.BITNET writes: >> >>Hello! I tried TURBODOS (downloaded from UH-INFO). Really impressing >>speed-up, BUT: It spoilt a disk. Apparently it did not recognize >>a disk change, and copied the old disk's FAT to the changed new disk. This wouldn't be a problem on a hard-disk (inkling of ignorance showing through) would it? tw Tom Wolf ARPA (I think): tw@cscosl.ncsu.edu or wolf@csclea.ncsu.edu
apratt@atari.UUCP (Allan Pratt) (04/16/88)
From article <1687@ncsuvx.ncsu.edu>, by wolf@csclea.ncsu.edu (Thomas Wolf): >> [TurboDOS's problems with media-change] > This wouldn't be a problem on a hard-disk, would it? Unfortunately, yes: just as your thumb is hardware which can eject a disk, your forefinger can reset the machine. This can happen with more regularity (say) than on a UNIX system, because it's so easy to lock up the system from a stupid user program and force a reboot. The only bad thing which could happen with the ROM GEMDOS is unclosed, newly-written-to files will be lost, and the data clusters either remain free or are orphaned. But if TurboDOS delays writes even longer, you could lose a lot more. I encourage people not to use TurboDOS -- I know I wouldn't trust my hard disk to it. If they didn't think media-change through, what else didn't they do? ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
gert@nikhefh.hep.nl (Gert Poletiek) (04/16/88)
In article <1687@ncsuvx.ncsu.edu> wolf@csclea.UUCP (Thomas Wolf) writes: >In article <451@nikhefh.hep.nl> gert@nikhefh.hep.nl (Gert Poletiek) writes: >>In article <8804131634.AA17900@ucbvax.Berkeley.EDU> WALDI@DHDIHEP1.BITNET writes: >>>Hello! I tried TURBODOS (downloaded from UH-INFO). Really impressing >>>speed-up, BUT: It spoilt a disk. Apparently it did not recognize >>>a disk change, and copied the old disk's FAT to the changed new disk. > >This wouldn't be a problem on a hard-disk (inkling of ignorance showing >through) would it? >Tom Wolf O YES II WOULD. How about when shutting down the system? Do you happen to have an equivalent of /etc/shotdown on your atari? Please recall what such a beast does! sync; sync; sync; When running TurboDos or any other fix for GemDos that preserves the DELAYED WRITE cache having removed the bugs in it from the original GemDos ALWAYS QUIT FROM THE APPLICATION THAT DID THE MOST RECENT MODIFICATION TO THE FILE SYSTEM. Unless ofcourse you like Damocles' sword... Gert Poletiek NIKHEF-H, Dutch National Institute for Nuclear and High Energy Physics Kruislaan 409, P.O.Box 41882, 1009 DB Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!nikhefh!gert bitnet: nikhefh!gert@mcvax.bitnet, U00025@hasara5.bitnet
mrd@sun.mcs.clarkson.edu (Michael R. DeCorte) (04/18/88)
Posting-Front-End: GNU Emacs 18.47.2 of Thu Dec 10 1987 on sun.mcs.clarkson.edu (berkeley-unix) In article <452@nikhefh.hep.nl> gert@nikhefh.hep.nl (Gert Poletiek) writes: In article <1687@ncsuvx.ncsu.edu> wolf@csclea.UUCP (Thomas Wolf) writes: >In article <451@nikhefh.hep.nl> gert@nikhefh.hep.nl (Gert Poletiek) writes: >>In article <8804131634.AA17900@ucbvax.Berkeley.EDU> WALDI@DHDIHEP1.BITNET writes: >>>speed-up, BUT: It spoilt a disk. Apparently it did not recognize >>>a disk change, and copied the old disk's FAT to the changed new disk. > >This wouldn't be a problem on a hard-disk (inkling of ignorance showing >through) would it? O YES II WOULD. How about when shutting down the system? Do you happen to have an equivalent of /etc/shotdown on your atari? Please recall what such a beast does! sync; sync; sync; Well, then does anyone have a sync for TurboDos? I would really like some documentation. (no, I am not being negative, just cautious)
c162-br@zooey.Berkeley.EDU (Warner Young) (04/19/88)
As I understand it, TurboDOS seems to do some disk caching, so
ejecting a floppy from your drive may cause disastrous things to happen
to the FAT, etc., etc. But if you exit an application, it flushes the
cache completely. So if you just have a really small program on your
disk that you could run, just run it and exit before you eject your
disk. It might be a little trouble, but it sounds to me like this would
solve the problem, as the cache would then get flushed to the disk when
you exit from your program. Can anyone tell me if I'm right?
\ /arner - Writer of the dreaded Safety Seal Reviews
\ / / - Owner of the vaporware group Safety Seal Software
\/ \_/oung
| - Disclaimer: I'm not associated with any of the companies
\_| above, in any way except (possibly) as a customer.tainter@ihlpg.ATT.COM (Tainter) (04/19/88)
In article <756@sun.mcs.clarkson.edu>, mrd@sun.mcs.clarkson.edu (Michael R. DeCorte) writes: >In article <1687@ncsuvx.ncsu.edu> wolf@csclea.UUCP (Thomas Wolf) writes: >>>>speed-up, BUT: It spoilt a disk. Apparently it did not recognize >>>>a disk change, and copied the old disk's FAT to the changed new disk. >>This wouldn't be a problem on a hard-disk (inkling of ignorance showing >>through) would it? >OH YES IT WOULD! How about when shutting down the system? Do you happen to >have an equivalent of /etc/shotdown on your atari? Please recall what such a >beast does! > sync; sync; sync; Actually, what Thomas posted is correct. The FAT corruption from failing to handle media change is not a problem on hard disks (no media change events!). On the otherhand, the sync problem Michael is talking about (and Allan was talking about) is a delayed write problem of another colour. Yes, if you do delayed write cacheing you are subject to loss on freezeup and power down, or media change. Note: UNIX has the same problems if you pull the cord or otherwise power down in an uncatchable manner. Ever wonder why AT&T machines don't really turn off when you turn the switch off? That's right sync time. --j.a.tainter
jmg@cernvax.UUCP (jmg) (04/19/88)
In article <1039@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: > >I encourage people not to use TurboDOS -- I know I wouldn't trust my >hard disk to it. If they didn't think media-change through, what else >didn't they do? I understand the point of view of Allan. However, what really irks me is that what he is saying is so negative. I would not have minded if Atari themselves were doing something. However, on all evidence they are doing sweet f*** a**: the blitter chip is still vapourware, I have no idea if/when/where I could get updated ROMs with less bugs etc. etc. Now, here we have something actually done to help ST users. OK, it is buggy (my set of auto and acc programs sometimes bomb, apparently because of including turbodos), but I am sure that with the interest which it has raised new versions will appear pretty soon as people disassemble it and fix the bugs. A nice attitude from Atari (gee, this guy is really a dreamer!) would be to help to fix it, not simply to decry it without any alternative offering (but then, would I believe it if Atari talked of an alternative offering Real Soon Now?). Allan, it is probably not your fault: I am flaming the wrong person. Nonetheless, try to be a bit more positive than just "don't use it". I personally will try it, with the reservation that every so often I will disable it and run DLII. (for those who may have noted that I could not run the new icon program, the fix is simple, since turbodos simply seems to move much of what was in low memory a bit further down. Thus, the icon replacement program just had to look for "DESKTOP.RSC" a bit further on in memory) -- _ _ o | __ | jmg@cernvax.uucp | | | | _ / \ _ __ _ __ _| jmg@cernvax.bitnet | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. DD, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland
kuebler@incas (04/19/88)
Written 8:57 pm Apr 15, 1988 by apratt@atari > > This wouldn't be a problem on a hard-disk, would it? > > Unfortunately, yes: just as your thumb is hardware which can eject a > disk, your forefinger can reset the machine. This can happen with > more regularity (say) than on a UNIX system, because it's so easy > to lock up the system from a stupid user program and force a reboot. > > The only bad thing which could happen with the ROM GEMDOS is unclosed, > newly-written-to files will be lost, and the data clusters either remain > free or are orphaned. But if TurboDOS delays writes even longer, you > could lose a lot more. > > I encourage people not to use TurboDOS -- I know I wouldn't trust my > hard disk to it. If they didn't think media-change through, what else > didn't they do? Some weeks ago I wrote a program to speed up the fat access when writing to harddisks. Unlike turbodos it is not replacing the file system of gemdos, but replaces the routine which searches for free clusters. No disk caching is done. It uses 30 k ram space; also included is a fix to the bombing C(con|prn|aux)out when redirected. So if anyone doesn't want to use turbodos because of its disadvantages, but is tyred of slow writing to his harddisk, he may be interested in this program. Tell me, and I will mail it. Uli Kuebler University of Kaiserslautern West-Germany ..!uunet!mcvax!unido!uklirb!kuebler