peter@nuchat.UUCP (Peter da Silva) (02/10/88)
Time for my periodic semicoherent flame about Amigados. It's STILL the least reliable file system I have ever used. When I complained about this here I received the following response: "Well don't work from floppies, copy everything to VD0: and do your thing from there" (paraphrased) Well, luckily for me I'm running with 4.5 megabytes of RAM and so I can do that. Other people don't have that option. Amigados is just plain flakey. Almost every disk error means you lose an entire track, thanks to the 1 sector per track concept (let's not argue about what a sector is, hey? As far as the electronics is concerned it's all one big sector). A good proportion of the time the lost track is the root track, unsurprisingly enough. Please, after you finish the fast file system... get a reliable on. It doesn't have to be big: 720K per diskette would be fine. But it needs to have real sectors to act as firewalls when corruption occurs (as it invariably does). Finally, I have a suggestion for the multitasking shuffle. Have LoadSeg keep a semaphore for each floppy, and single-thread itself. Make Copy respect it. And publish how to use it so that we can make our utilities do the same thing. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
kasper@russell.STANFORD.EDU (Kasper Osterbye) (02/11/88)
Never lost a single bit on my floppies in the half a year I had my machine - I had to use disk doctor once, but later on there was no problem with the data on that disk - I silly head did not even bother to reinstall it. The floppies even gets lots of tobacco, and flying ashes - no problem - safe as a train. /Kasper internet: kasper@russell.stanford.edu
dillon@CORY.BERKELEY.EDU (Matt Dillon) (02/11/88)
>Please, after you finish the fast file system... get a reliable on. It doesn't >have to be big: 720K per diskette would be fine. But it needs to have real >sectors to act as firewalls when corruption occurs (as it invariably does). Silly, they *are* real sectors... they simply do not have the *space* normally put between sectors. The problem is with the way AmigaDOS and the trackdisk.device handle it. One major improvment, and one reason why IBM-PC harddisks/floppies seem more reliable, is to put in lots of self-checking in the software... "do I *really* want to do this operation.. lets check this structure checksum here, that structure checksum over there ... ho hum, I guess it's ok, start the DMA". Another reason PC disk drivers seem more reliable is the inherent single tasking nature of the PC.. it usually doesn't freeze in the middle of a disk operation. -Matt
dillon@cory.Berkeley.EDU (Matt Dillon) (02/12/88)
[This is Bryce Nesbitt- Please don't try to mail any mail intended for me... things are broken at the moment] In article <644@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >Time for my periodic semicoherent flame about Amigados. > >...Almost every disk error means you lose an >entire track, thanks to the 1 sector per track concept... No, no, no. Cause and effect is all messed up here. Your disk errors have a cause, but I maintain that it is not AmigaDOS proper that is causing them. The trackdisk.device is the responsible entity. I'll get to that in a moment, but first: IF YOU ARE HAVING CONSTANT READ ERRORS, EITHER YOUR DISKS OR DRIVES ARE DEFECTIVE, AND MUST BE FIXED. Ok. When trackdisk has a buffer of partially good, and partially bad, sectors, it often will loose the entire track. This has nothing to do with the "one track per revolution" disk format scheme used. Instead trackdisk simply does not have enough brains to see that there is a problem. Trackdisk should have a bunch of options, including writing out the data many times so that the bad spot on the disk matches the already bad sector or the tail gap. This saves whatever good data that was on the track. In general, trackdisk leaves a lot of tricks untried as far as dealing with cripple disks. The Slow File System (SFS) has a lot of redundancy that compensates. Many of the OS utilities swing the other way. For example, FORMAT will retry many times. Here you have this disk that format had to retry 5 times, and you want to write data on it? The least format could do is tell you that the disk might not be perfect. Bad block mapping within trackdisk probably won't work under SFS, but I could be surprised. PS: I'm convinced that a disk that is bad during manufacture is never actually thrown away... it just gets passed to the next lower/cheaper disk distributor :-). PPS: Random thought on AmigaDOS design: The checksum and redundancy area of AmigaDOS is put at the start of the sector. This makes sector-by-sector DMA inconvenient. If the same data was at the END of the block, DMA would be different. You could DMA the entire block in, past it's local end. Check it while the controller perpares the next sector. Now overwrite the first block's redundant area with the next sector. Only the last sector would need a special case. |\_/| . ACK!, NAK!, EOT!, SOH! {o o} . Bryce Nesbitt (") BIX: mleeds (temporarily) U Don't send mail... it won't get here.
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (02/12/88)
In article <644@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >Please, after you finish the fast file system... get a reliable on. It doesn't >have to be big: 720K per diskette would be fine. But it needs to have real >sectors to act as firewalls when corruption occurs (as it invariably does). > ^^^^^^^^^^^^^^^^^^^ At last! Phrased in a way I understand, and agree with. I would not argue with such a change. However, I'd supply the counterpoint that I, personally, have very rarely had problems with disk corruption (I can think of only one incident). Either I'm leading a blessed life, or Peter's drives may be a teensy bit off spec. Realize that I'm just guessing, however. And now, the real point of this posting: >Finally, I have a suggestion for the multitasking shuffle. Have LoadSeg keep >a semaphore for each floppy, and single-thread itself. Make Copy respect it. >And publish how to use it so that we can make our utilities do the same >thing. (Motion of hand moving rapidly over head whilst uttering, "Whoosh!") Huh?? Could you clarify that one; you lost me completely. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
daveh@cbmvax.UUCP (Dave Haynie) (02/12/88)
> Time for my periodic semicoherent flame about Amigados. You're actually flaming the trackdisk.device... > It's STILL the least reliable file system... Amigados is just plain flakey... No, I know some folks can't resist the urge to flame the DOS. Hey, all that BCPL code must be doing something wrong, eh? And the main problem isn't that full tracks are read and written in one pass. The problem is that, each time that full track is written, it could start anywhere. So, given enough writes, if you have a place that'll drop a bit on that track, it'll eventually wind up having your important data written on top of it. The ideal solution would be to have trackdisk start it's writes at the same place every time. Then you should be able to add bad block mapping -- even though the blocks aren't distinct, as long as they get written in the same place every time, and you avoid placing meaningful data in a known bad place, your reliability will go up quite a bit. > Almost every disk error means you lose an entire track, thanks to the 1 > sector per track concept (let's not argue about what a sector is, hey? As > far as the electronics is concerned it's all one big sector). A good > proportion of the time the lost track is the root track, unsurprisingly > enough. The root track contains the bitmap, which gets rewritten all the time, so you would expect that to be the first to go. Fortunately, the way DOS formats the disk, you can loose ROOT and BITMAP and still recover everything. Of course, you'd rather not have to recover it, eh? And though you're correct about DOS and DiskSalv and DiskDoctor giving up on a whole track when it goes, I don't think that for either a write or a read this should be necessary. The worst case loss would be when you die in the middle of a write; you could end up with 2 copies of about 1/2 the blocks in that track. If you just lay out one block on a glitchy section of a track, I think you should be able to get most everything back. It would certainly require very low level programming at this point, maybe all the way down at the disk.resource. > Please, after you finish the fast file system... get a reliable on. It doesn't > have to be big: 720K per diskette would be fine. But it needs to have real > sectors to act as firewalls when corruption occurs (as it invariably does). Amigas can read and write PC-DOS compatible files on PC formatted disks. That says to me that block syncing is also possible. It's impossible for the hardware to write less than a track, far as I know, so true sectors are out. But a synced track read/write should be just as secure at 11 logical sectors as it would be with 9. > Finally, I have a suggestion for the multitasking shuffle. Have LoadSeg keep > a semaphore for each floppy, and single-thread itself. Make Copy respect it. > And publish how to use it so that we can make our utilities do the same > thing. Now there's a DOS issue, and I fully agree that the disk thrashing you get into is a needed fix. If we get a handler in the future that asks for more than single blocks at a time, this should smoothen things out a bit. > -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' > -- normally ...!hoptoad!academ!uhnix1!sugar!peter U > -- Disclaimer: These aren't mere opinions... these are *values*. -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
kent@xanth.cs.odu.edu (Kent Paul Dolan) (02/12/88)
In article <644@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >Time for my periodic semicoherent flame about Amigados. > [...] >Amigados is just plain flakey. Almost every disk error means you lose an >entire track, thanks to the 1 sector per track concept (let's not argue >about what a sector is, hey? As far as the electronics is concerned it's >all one big sector). A good proportion of the time the lost track is >the root track, unsurprisingly enough. > >Please, after you finish the fast file system... get a reliable on. It doesn't >have to be big: 720K per diskette would be fine. But it needs to have real >sectors to act as firewalls when corruption occurs (as it invariably does). Another suggestion (since I don't like giving up that much storage): when an error occurs writing a track, and before the data is lost, write the whole track to track 81, STOP ALL FURTHER WRITING TO THE DISK, put up a requestor for a blank recovery disk, suspend the calling task; let the user recover onto a blank disk, with a program that restores the bad track from track 81 and makes an exact duplicate of the disk creation info to make the suspended program happy with the disk as a clone of the damaged one, and reschedule the task. I find that even with disksalv, I'm typically getting back less than 60% of the disk data; I attribute that to having the process continue to try to write to a disk that already has serious problems. Considering the undependability of floppy media, I think the driver should incorporate full write error recovery directly, to minimize damage to other diskette files. Comments? Kent, the man from xanth.
charles@hpcvca.HP (Charles Brown) (02/13/88)
>>Please, after you finish the fast file system... get a reliable on. >>It doesn't have to be big: 720K per diskette would be fine. But it >>needs to have real sectors to act as firewalls when corruption >>occurs (as it invariably does). > Silly, they *are* real sectors... they simply do not have the >*space* normally put between sectors. The problem is with the way >AmigaDOS and the trackdisk.device handle it. Wasn't it posted here that the Amiga does not wait until the index mark to write out the track? That is the real reason the sectors do not act as firewalls. The physical location of any particular sector on the track is random from one write to the next. Thus an error in one sector (or even in the gap) may appear in any other sector with the next write. Clearly, the cost of fixing this reliability problem is performance. Each track write will take up to twice as long because of the disk rotation latency. Sigh... > One major improvment, and one reason why IBM-PC >harddisks/floppies seem more reliable, is to put in lots of >self-checking in the software... "do I *really* want to do this >operation.. lets check this structure checksum here, that structure >checksum over there ... ho hum, I guess it's ok, start the DMA". One thing I liked from some CP/M systems was being able to read a disk knowing there were errors. SECTOR READ ERROR. A=Abort, I=Ignore, R=Retry. Most of the files I cared about were text. Ignoring the error allowed me to reconstruct most of the file. I could then edit out the junk introduced by the sector error. Of course, this may not be ideal for an unsophisticated user. But in a less than perfect world we often have to put up with less than perfect solutions. After all, the perfect solution is a disk which does not make errors. > Another reason PC disk drivers seem more reliable is the inherent >single tasking nature of the PC.. it usually doesn't freeze in the middle of >a disk operation. > -Matt It also does not pause... and then write to the disk just when you were about to reboot. I have trained myself to wait 5 seconds after the LED goes out before I reboot. The Amiga is the only computer I have needed this for. charles@hp-pcd
haitex@pnet01.cts.com (Wade Bickel) (02/15/88)
charles@hpcvca.HP (Charles Brown) writes: >One thing I liked from some CP/M systems was being able to read a disk >knowing there were errors. > SECTOR READ ERROR. A=Abort, I=Ignore, R=Retry. >Most of the files I cared about were text. Ignoring the error allowed >me to reconstruct most of the file. I could then edit out the junk >introduced by the sector error. Of course, this may not be ideal for >an unsophisticated user. But in a less than perfect world we often >have to put up with less than perfect solutions. After all, the >perfect solution is a disk which does not make errors. > You might try a PD program called DiskX. I found it on DevWare's DevDisk 0026. It is crude but can be used for retrieving text as you described. >It also does not pause... and then write to the disk just when you >were about to reboot. I have trained myself to wait 5 seconds after >the LED goes out before I reboot. The Amiga is the only computer I >have needed this for. Yes, this is a problem. So far I've had 4 disks go bad on me, two of them for this very reason. I too have become very carefull about removing floppies. A simple solution would be to leave the LED on until no more jobs are queued for the drive. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
shimoda@rmi.UUCP (Markus Schmidt) (02/15/88)
Matt said something like "pc-dos disks seem safer". I do not agree to that. Hit a track 0 on an pc-dos-disk (the FAT) and you have lots of sectors which are ok, but trash, since theres no connection between them. On the other hand you can format track 0 and track 40 on an AMIGADOS- Disk and Diskdoctor will still be able to find lots of the files. Urs, Markus (shimoda@rmi.UUCP)
keithd@cadovax.UUCP (Keith Doyle) (02/16/88)
In article <4410018@hpcvca.HP> charles@hpcvca.HP (Charles Brown) writes: >One thing I liked from some CP/M systems was being able to read a disk >knowing there were errors. > SECTOR READ ERROR. A=Abort, I=Ignore, R=Retry. >Most of the files I cared about were text. Ignoring the error allowed >me to reconstruct most of the file. I could then edit out the junk >introduced by the sector error. Unless the sector you lost was on one of the directory tracks, as then you were totally screwed because there was no way to tell which blocks belonged to which file. I seem to remember writing a "salvage" program that would allow me to try to visually match the text at the end of a block with that of various potential 'next blocks'. GAK. No thanks. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (02/16/88)
In article <2539@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > [ ... ] So far I've had 4 disks go bad on me, two >of them for this very reason. I too have become very carefull about removing >floppies. A simple solution would be to leave the LED on until no more >jobs are queued for the drive. > This is the case with the 1000. The LEDs reflect the true status of drive activity. However, when it came time to create the 2000, something got lost in the translation. Apparently, there is a flip-flop in the drives or drive controllers which controls the state of the drive LED in the 1000. When it's on, the drive is in use. When it's off, it's *off*. Evidently, some engineer at Braunschweig couldn't figure out what this flip-flop was for, decided it served no useful purpose, and diked it out of the 2000 design. And so now some users are having problems with corrupted disks because they're removing them from the drives too soon, or killing power too soon. This story is my interpretation of a story related to me by a former C-A engineer, so it may be mutated from the actual truth. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
tadguy@xanth.cs.odu.edu (Tad Guy) (02/18/88)
In article <5249@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <2539@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: >>A simple solution would be to leave the LED on until no more >>jobs are queued for the drive. >> >This is the case with the 1000. The LEDs reflect the true status of >drive activity. However, when it came time to create the 2000, something >got lost in the translation. > > Evidently, some engineer at Braunschweig couldn't figure out what >this flip-flop was for, decided it served no useful purpose, and diked it >out of the 2000 design. [ ...and thereby saving Commodore millions in production costs... :-( ] Or it may be the drive manufacturer... I have a pair of Toshiba FDS-362's connected to my A1000. The LED on these drives is gated by read/write activity, not by motor activity. The result is that even though the motor is running, the light on the drive only lights when io is actually occuring to/from the disk. If I use a NEC drive in place of one of the Toshibas the LED works as expected. I added a second LED to the drive to follow the state of the real LED line, and kept the other LED as it is. It's sorta neat to see when the disk io is really occuring compared to when the motor is just runing. ...tad Tad Guy (804)-440-4529 UUCP: tadguy@xanth.UUCP Department of Computer Science or: ...!uunet!xanth!tadguy Old Dominion University new ARPA: tadguy@cs.odu.edu Norfolk, Virginia 23529-0162 old ARPA: tadguy%xanth.UUCP@SUN.COM
morgan@brambo.UUCP (Morgan W. Jones) (02/18/88)
In article <5220@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <644@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >>Finally, I have a suggestion for the multitasking shuffle. Have LoadSeg keep >>a semaphore for each floppy, and single-thread itself. Make Copy respect it. >>And publish how to use it so that we can make our utilities do the same >>thing. > (Motion of hand moving rapidly over head whilst uttering, "Whoosh!") > Huh?? Could you clarify that one; you lost me completely. Semaphores are a mechanism used to ensure that critical portions of code are not executed at the same time by two concurrent tasks. Single-thread means that a given floppy drive is only accessed by one device at a time. So what the whole thing boils down to is that when LoadSeg is asked to load a program, it would lock on a semaphore for the device that it wants to load from (preventing other processes from using the device until LoadSeg is done), loading the program, and then releasing the semaphore. Thus, you would never get two processes trying to access the device at the same time and causing the heads to bump and grind back and forth getting sectors(tracks?). But this really isn't a good idea. It might work fine if all you did was load programs, but it wouldn't do much for accessing data files. Either you would get the bump and grind, or else you would get processes waiting arbitrarily long for I/O because some other program has a semaphore and is processing data. A better solution is to have buffered I/O provided by the operating system where the OS acquires a semaphore on a drive, reads in x number of blocks and then releases the semaphore and lets the program process the data; this would work equally well for both program files and for data files. Then we can all stop trying to arrange our programs so that no two of them try to access drives at the same time. >Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ -- Morgan Jones - Bramalea Software Inc. ...!utgpu!telly \ !brambo!morgan ...!{uunet!mnetor, watmath!utai}!lsuc!ncrcan / "These might not even be my opinions, let alone anyone else's."
peter@nuchat.UUCP (Peter da Silva) (02/18/88)
In article ... dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >Please, after you finish the fast file system... get a reliable on. It doesn't > >have to be big: 720K per diskette would be fine. But it needs to have real > >sectors to act as firewalls when corruption occurs (as it invariably does). > Silly, they *are* real sectors... they simply do not have the > *space* normally put between sectors. The problem is with the way AmigaDOS > and the trackdisk.device handle it. They don't work like real sectors. There's no reason they need to be real sectors... they're just logical divisions on a track. They might have sector headers and be encoded in MFM, but there's really no reson for it given how they're used. > One major improvment, and one reason why IBM-PC harddisks/floppies > Another reason PC disk drivers seem more reliable is the inherent > single tasking nature of the PC.. it usually doesn't freeze in the middle of > a disk operation. The main reason is that a bad sector doesn't corrupt the rest of the sectors on the track. A bad spot has about an 11% (1/9) chance of hitting a given sector on the PC, but a 100% chance on the Amiga... because they're not really sectors. UNIX is multitasking and has a much greater reliability track record than AmigaDOS (or PC-DOS), so you're just wasting your time making that the scapegoat. UNIX uses real sectors, and UNIX checks for and recovers from disk errors. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (02/19/88)
>UNIX is multitasking and has a much greater reliability track record than >AmigaDOS (or PC-DOS), so you're just wasting your time making that the >scapegoat. UNIX uses real sectors, and UNIX checks for and recovers from >disk errors. UNIX also has an MMU. In all my life I've only crashed a VAX running UNIX 3 or 4 times. UNIX may or may not use real sectors, because it is the drive hardware, not UNIX that determines this. We used to have a Perkin-Elmer something or other running 4.2BSD ... It had a CDC drive which reads and writes entire tracks at a time... you want to read a sector, it reads the whole track. You want to write a sector, it writes the whole track (via an intelligent track caching scheme). -Matt
peter@nuchat.UUCP (Peter da Silva) (02/21/88)
In article <3311@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > > Time for my periodic semicoherent flame about Amigados. > You're actually flaming the trackdisk.device... OK, I'm flaming the trackdisk.device, I... *what*? > And the main problem isn't that full tracks are read and written in one pass. You mean there's no way to avoid that???? > The problem is that, each time that full track is written, it could start > anywhere. So, given enough writes, if you have a place that'll drop a bit > on that track, it'll eventually wind up having your important data written > on top of it. Yeh, that was what I was getting at. Well, now... > The ideal solution would be to have trackdisk start it's writes at the same > place every time. Yeh, that should solve the problem. Perhaps. > Then you should be able to add bad block mapping -- even > though the blocks aren't distinct, as long as they get written in the same > place every time, and you avoid placing meaningful data in a known bad > place, your reliability will go up quite a bit. Yeh, that's the ticket. So, when are we going to see the fix? And the fix for the Delay(0) bug, too. I have this funny feeling that it's partially responsible. I've removed most of my resident junk, and it hasn't gotten any better... but you never can tell. Does anyone know if wkeys or snipit have the Delay(0) bug in them? > The root track contains the bitmap, which gets rewritten all the time, so you > would expect that to be the first to go. Fortunately, the way DOS formats > the disk, you can loose ROOT and BITMAP and still recover everything. Of > course, you'd rather not have to recover it, eh? Yeh, that's true. These days I'm using DiskSalv more often than dPaint. > Amigas can read and write PC-DOS compatible files on PC formatted disks. That > says to me that block syncing is also possible. Why? MS-DOS doesn't care where sectors start. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
peter@nuchat.UUCP (Peter da Silva) (02/21/88)
In article <5220@well.UUCP>, ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > Either I'm leading a blessed life, or Peter's drives may be a teensy bit off > spec. Realize that I'm just guessing, however. Well, it doesn't seem to care what drive I'm using... and I think it unlikely that both of my drives would be off by the same amount. > And now, the real point of this posting: > In article <644@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > >Finally, I have a suggestion for the multitasking shuffle. Have LoadSeg keep > >a semaphore for each floppy, and single-thread itself. Make Copy respect it. > >And publish how to use it so that we can make our utilities do the same > >thing. > (Motion of hand moving rapidly over head whilst uttering, "Whoosh!") > Huh?? Could you clarify that one; you lost me completely. The multitasking shuffle is what happens when you accidentally try to load two programs from the same floppy at one time. You get: Read 1 block from c:FOO Grind/seek. Read 1 block from c:BAR Grind/seek. Read 1 block from c:FOO... If LoadSeg was an atomic (or single-threaded) operation this wouldn't be a problem. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
peter@nuchat.UUCP (Peter da Silva) (02/21/88)
In article ... dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >UNIX is multitasking and has a much greater reliability track record than > >AmigaDOS (or PC-DOS), so you're just wasting your time making that the > >scapegoat. UNIX uses real sectors, and UNIX checks for and recovers from > >disk errors. > UNIX also has an MMU. In all my life I've only crashed a VAX running > UNIX 3 or 4 times. This is definitely a point in its favor, though UNIX on the IBM-PC/XT does not have an MMU and doesn't seem to generate as many errors. *But*, I've not been talking about situations where I crashed out during a write. That sort of thing I expect. What I'm bitching about is that I lose stuff when everything's just coasting along fine, too... ALSO, when an error does occur UNIX recovers *much* better than AmigaDOS. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
john13@garfield.UUCP (John Russell) (02/25/88)
In article <661@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > >Yeh, that's true. These days I'm using DiskSalv more often than dPaint. Check your drive. My old one used to work fine using the Marauder-II speed check... except for occasionally it would go for about one second at *3* RPM according to M-II. I could make it do this consistently by tilting the drive -- I don't suppose you've got it on its side? John -- "Fanaticism is all right... as long as you're ALONE! HAHAHAHA!" -- Pat Robertson shares a gem of wisdom told to him by Richard Nixon, and thus becomes the first politician to whom I can honestly apply the term "scares the willies out of me"
peter@nuchat.UUCP (Peter da Silva) (02/29/88)
In article <4532@garfield.UUCP>, john13@garfield.UUCP (John Russell) writes: > In article <661@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > >Yeh, that's true. These days I'm using DiskSalv more often than dPaint. > Check your drive. My old one used to work fine using the Marauder-II speed > check... except for occasionally it would go for about one second at *3* > RPM according to M-II. I could make it do this consistently by tilting the > drive -- I don't suppose you've got it on its side? No, I had one of my drives on its side for about 2 hours once, but I didn't like the sounds it made and it seemed even less reliable while I was doing this. I suspect that I'm actually suffering from the delay(0) bug. Anyone know if there's a SetFunction patch for Delay? I can't figure out what I could be running that delay(0)s... -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.