peter@sugar.UUCP (Peter da Silva) (01/02/88)
I'm starting to get a mite tired of losing files to disk errors when I ZZ out of Z. I can't see why a bad block should ever produce a file with errors on a write. If I'm writing the file to disk and the driver gets a bad block, it should tell that to DOS, and DOS should say "Ah, I'll mark that block BAD and try another one". While I'm on this subject, how about dumping the "one sector per track" business and going to a conventional track/sector type arrangement? What you lose in rotational latency you more than gain in reliability. Hell, you can even read a track at a time ANYWAY. No skin off my nose. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
schein@cbmvax.UUCP (Dan Schein CATS) (01/05/88)
In article <1338@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >I'm starting to get a mite tired of losing files to disk errors when I >ZZ out of Z. I can't see why a bad block should ever produce a file with I use Z on 4 different Amigas. Some with floppies only and some with floppies and hard drives. Some with ram: some with vdk: and I have never lost a file when exiting (ZZ) from Z. I have no idea what is causing your problems, but here is a workaround. Use the ":" "r filename" approach to save your file. This way you write the file without exiting Z. So is and error occurs, the file is not lost. If the write is sucessfull, use the ":" "q!" approach to exit Z. >-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Dan Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein Commodore AMIGA ARPANET: cbmvax!schein@uunet.uu.net 1200 Wilson Drive Bix: dschein Plink: Dan*CATS West Chester PA 19380 phone: (215) 431-9100 ext. 9542 +----------------------------------------------------------------------------+ All spelling mistakes are a result of my efforts to avoid education :-) +----------------------------------------------------------------------------+ I help Commodore by supporting the AMIGA. Commodore supports me by allowing me to form my own suggestions and comments.
cmcmanis%pepper@Sun.COM (Chuck McManis) (01/05/88)
In article <1338@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >While I'm on this subject, how about dumping the "one sector per track" >business and going to a conventional track/sector type arrangement? What >you lose in rotational latency you more than gain in reliability. Hell, >you can even read a track at a time ANYWAY. No skin off my nose. Uh, Peter, we do have multiple sectors/track. About 11 last time I checked. I agree that writing to a disk with a bad block should not be fatal, however with the current filesystem it would cause problems with conventional disk interfaces (like using a WD or NEC chip) as well. The most you should lose is one block of one file, everything else can be recovered from information on the disk. As a Request For Enhancement, I think it would be nice to add a 'bad block' bitmap. If a new mount command with user selectable file systems is created you could do it that way. (Or get down and dirty and replace the task pointer in the device nodes, handler task with one of your own.). --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
jmpiazza@sunybcs.uucp (Joseph M. Piazza) (01/05/88)
In article <3080@cbmvax.UUCP> schein@cbmvax.UUCP (Dan Schein CATS) writes: >In article <1338@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >>I'm starting to get a mite tired of losing files to disk errors when I >>ZZ out of Z. I can't see why a bad block should ever produce a file with > > I use Z on 4 different Amigas. Some with floppies only and some with > floppies and hard drives. Some with ram: some with vdk: and I have never > lost a file when exiting (ZZ) from Z. I have no idea what is causing your > problems, but here is a workaround. Use the ":" "r filename" Just a few corrections ... That should be "w" for write, rather than "r" for read. Also, using "w" without a file name will write to the file specified when running Z -- no need to type out the entire filename each time (I hate typingk). If you didn't give a filename (perfectly legit) it responds "Can't open output file" (I just tested it -- ah, multi-tasking). > ... approach > to save your file. This way you write the file without exiting Z. So is > and error occurs, the file is not lost. If the write is sucessfull, use > the ":" "q!" approach to exit Z. > Use the "q" command WITHOUT the "!" and Z will protect you from throwing away your changes by refusing to quit. Using the "!" in the command ( as in "q!") over-rides this protection. You would use the over-ride in cases when you DON'T want the file saved to disk (like when you screwed up your file and DON'T want it saved, or like when you just want to read a file). It amazes me that many Amiga applications don't even give you this simple form of protection. I've never had any problems and have never used the ZZ command (well, maybe once or twice when I didn't know what I was doing. :-) Flipside, joe piazza --- In capitalism, man exploits man. In communism, it's the other way around. CS Dept. SUNY at Buffalo 14260 UU: ...{rocksvax|decvax}!sunybcs!jmpiazza CS: jmpiazza@cs.buffalo.edu BI: jmpiazza@sunybcs > Dan Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein
schein@cbmvax.UUCP (Dan Schein CATS) (01/05/88)
In article <7638@sunybcs.UUCP> jmpiazza@gort.UUCP (Joseph M. Piazza) writes: >In article <3080@cbmvax.UUCP> schein@cbmvax.UUCP (Dan Schein CATS) writes: >>In article <1338@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >>>I'm starting to get a mite tired of losing files to disk errors when I >>>ZZ out of Z. I can't see why a bad block should ever produce a file with >> >> I use Z on 4 different Amigas. Some with floppies only and some with >> floppies and hard drives. Some with ram: some with vdk: and I have never >> lost a file when exiting (ZZ) from Z. I have no idea what is causing your >> problems, but here is a workaround. Use the ":" "r filename" > > Just a few corrections ... > > That should be "w" for write, rather than "r" for read. Also, using >"w" without a file name will write to the file specified when running Z -- no >need to type out the entire filename each time (I hate typingk). >If you didn't give a filename (perfectly legit) it responds "Can't open output >file" (I just tested it -- ah, multi-tasking). > OPPS! (Red faced) You are right - I did mean "w" and not "r". >> ... approach >> to save your file. This way you write the file without exiting Z. So is >> and error occurs, the file is not lost. If the write is sucessfull, use >> the ":" "q!" approach to exit Z. >> > Use the "q" command WITHOUT the "!" and Z will protect you from >throwing away your changes by refusing to quit. Using the "!" in the >command ( as in "q!") over-rides this protection. You would use the >over-ride in cases when you DON'T want the file saved to disk (like >when you screwed up your file and DON'T want it saved, or like when you >just want to read a file). I recommended the r filename approach so that the file *WOULD* be written under a new (different) name, then exiting using the q! option would leave the original file untouched and the edited file under the new name. (Similar to what ZZ does by saving the unedited original as filename.bak) > It amazes me that many Amiga applications don't even give you this >simple form of protection. > > I've never had any problems and have never used the ZZ command >(well, maybe once or twice when I didn't know what I was doing. :-) > >Flipside, > > joe piazza > -- Dan Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein Commodore AMIGA ARPANET: cbmvax!schein@uunet.uu.net 1200 Wilson Drive Bix: dschein Plink: Dan*CATS West Chester PA 19380 phone: (215) 431-9100 ext. 9542 +----------------------------------------------------------------------------+ All spelling mistakes are a result of my efforts to avoid education :-) +----------------------------------------------------------------------------+ I help Commodore by supporting the AMIGA. Commodore supports me by allowing me to form my own suggestions and comments.
steveb@cbmvax.UUCP (Steve Beats) (01/05/88)
In article <37823@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: > >.......... As a Request For Enhancement, I think it would be nice to add >a 'bad block' bitmap. If a new mount command with user selectable file >systems is created you could do it that way. ........................... I know I'm going to get roasted for this one but here goes anyway. I don't believe that bad block mapping should be a function of the file system. We have hddisk.device that handles bad block mapping on ST506 devices and the SCSI devices usually handle this themselves. Putting BBM into a filesystem that is going to work with both of these types of media AND with floppies too (and any other kind of track/sector oriented device) is really piling on the redundancy, right? Quoting sugar!peter, "There should be a little back fence chatting" between the file system and the device. I whole-heartedly agree with this when it comes to header and data organisation, put data on consecutive sectors, start headers on track boundaries etc. etc. However, should a bad block appear in the middle of an existing file, I maintain that it is the devices job to map the bad block to a new place. This should be done in a manner that doesn't mess up the data organisation maintained by the file system, ie. do the back-fence-chatting both ways. After all, a file system is supposed to be a high-level interface to a low-level device/media. It is perfectly reasonable for the file system to assume it has ALL the sectors in the given partition. I think most of this discussion developed over the floppy file system. Once again, I maintain that bad block (actually track) mapping should have been a function of trackdisk.device and not the file system. I'm currently finishing the FFS and I know for sure that retro-fitting bad block mapping would be a royal pain in the butt. However, it isn't nescessary because all of the devices it accesses handle the mapping themselves. >.............................................. (Or get down and dirty and >replace the task pointer in the device nodes, handler task with one of your >own.). I guess my answer to this is to replace the device node with your own :-) >--Chuck McManis Steve
cjp@antique.UUCP (Charles Poirier) (01/06/88)
In article <37823@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <1338@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >>While I'm on this subject, how about dumping the "one sector per track" >>business and going to a conventional track/sector type arrangement? What > >Uh, Peter, we do have multiple sectors/track. About 11 last time I checked. >I agree that writing to a disk with a bad block should not be fatal, however >with the current filesystem it would cause problems with conventional disk >interfaces (like using a WD or NEC chip) as well. The most you should lose >is one block of one file, everything else can be recovered from information >on the disk. As a Request For Enhancement, I think it would be nice to add >a 'bad block' bitmap.... First, it seems to me that Peter is referring to the "no inter-sector gaps" track layout when he says "one sector". I think I see a potential problem with this system. What I recall (sorry if this is all wet) is that to write a block, a track is read in, the proper block of it is found and modified, and the track is then blasted back out. The Amiga doesn't sync the drive to a particular point before writing the track. So, if a bad spot develops on the disk, that spot may appear in any of the 11 blocks after a write to any of those blocks. The more of those blocks that are written to, the more of them will be corrupted by being dropped back on top of the oxide hole. What is needed, then, is a bad-track bitmap, not just bad blocks. Upon detecting an error, the file system should move all blocks of the track, which *are* readable, to other track[s]. (Something like that anyway.) -- Charles Poirier (decvax,ihnp4,attmail)!vax135!cjp "Docking complete... Docking complete... Docking complete..."
peter@sugar.UUCP (Peter da Silva) (01/06/88)
OK. Let's get this straight. I wasn't flaming Manx, I was flaming you. In article <3080@cbmvax.UUCP>, schein@cbmvax.UUCP (Dan Schein CATS) writes: > In article <1338@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >I'm starting to get a mite tired of losing files to disk errors when I > >ZZ out of Z. I can't see why a bad block should ever produce a file with This is a symptom. The problem is that when you write a file and it tries to write to a block that's bad, AmigaDOS should switch to a block that's good. It's GOT all of the block in memory already. What's the big deal... > I use Z on 4 different Amigas. Some with floppies only and some with > floppies and hard drives.... I have no idea what is causing your > problems... It is NOT a problem with Z. The only problem I have with Z is that F1 is mapped to ":x<CR>", so it's too easy to accidentally quit when you miss the space bar. I have had problems with other programs than Z. The problem is with disk errors. Maybe I need to use better floppies. Maybe I need to find out what program is doing a Delay(0) (semi-smiley). In the meantime I need a more reliable file system. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
peter@sugar.UUCP (Peter da Silva) (01/06/88)
In article <37823@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > In article <1338@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >While I'm on this subject, how about dumping the "one sector per track" > >business and going to a conventional track/sector type arrangement? > Uh, Peter, we do have multiple sectors/track. About 11 last time I checked. Not really. You sort of have multiple sectors in that the operating system supports reading and writing less than a whole track by reading the track, changing a sector, and writing it out again. You don't have multiple sectors in the classical sense, where the basic hardware operation is to read and write a single sector. If you get a disk error on a track, you basically have to write off (heh) that entire track. > I agree that writing to a disk with a bad block should not be fatal, however > with the current filesystem it would cause problems with conventional disk > interfaces (like using a WD or NEC chip) as well. Yes, and that's a seperate issue that I addressed in the body of the article. > The most you should lose > is one block of one file, everything else can be recovered from information > on the disk. Well, actually, you can lose up to 11 blocks of 1 file, or 1 block of 11 files, or... -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
schein@cbmvax.UUCP (Dan Schein CATS) (01/10/88)
In article <1368@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >OK. Let's get this straight. I wasn't flaming Manx, I was flaming you. > Seems to be a new sport :-) (Bytes saved & Text deleted) >It is NOT a problem with Z. The only problem I have with Z is that F1 is mapped > >The problem is with disk errors. > I think you could have been just a bit clearer on your original posting. I very seldom ever use floppies for anything but storage. I use VDK: (RRD) to do my work in, that may be why I never noticed the problems your having. >-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Dan Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein Commodore AMIGA ARPANET: cbmvax!schein@uunet.uu.net 1200 Wilson Drive Bix: dschein Plink: Dan*CATS West Chester PA 19380 phone: (215) 431-9100 ext. 9542 +----------------------------------------------------------------------------+ All spelling mistakes are a result of my efforts to avoid education :-) +----------------------------------------------------------------------------+ I help Commodore by supporting the AMIGA. Commodore supports me by allowing me to form my own suggestions and comments.
peter@sugar.UUCP (Peter da Silva) (01/16/88)
Once upon a time an Amiga Guru was approached by a Zen master, who was having a problem with AmigaDOS. The Guru suggested the Zen master show him the problem, so they went into the Guru's office. The Guru went out to get a cup of coffee while the Zen master played with the Guru's high zoot Amiga. When the Guru came back the Zen master waved the pointer (which was shaped like a mouse) over a window, saying "what's this?" The Guru said "Oh, that's just my pointer". The Zen master hit him over the head with a copy of the ROM Kernel Manual and turned off the Amiga. In article <3117@cbmvax.UUCP>, schein@cbmvax.UUCP (Dan Schein CATS) writes: > In article <1368@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >OK. Let's get this straight. I wasn't flaming Manx, I was flaming you. OK. Let's get this straight... > > > >The problem is with disk errors. > I think you could have been just a bit clearer on your original posting. > I very seldom ever use floppies for anything but storage. I use VDK: (RRD) > to do my work in, that may be why I never noticed the problems your having. Before I hit you over the head with a copy of the ROM Kernel manual, would you like to explain why that's relevent? I just used the example of 'Z' because it was the particular instance where I ran into the problem. It could happen anywhere, and it's equally annoying wherever it happens. You can cut things down by not writing to floppies that often, but the problem remains. Eventually it's going to bite you. The problem is that (1) the Amiga is very susceptible to disk errors, and (2) that the file system should NOT abort writing a file just because it gets a disk error. (1) can be solved by going to a more robust file system (like having real sectors on the tracks). (2) can be solved by trying to rewrite the offending block on a new track. Then, at least, the file could be saved. I'd MUCH rather have the file system AND the device driver try to recover than neither doing so, which is where I am now. Now, does the Amiga have buddha-nature? PS: Apologies to the author of "AI Koans". It just seemed so appropriate. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
schein@cbmvax.UUCP (Dan Schein CATS) (01/18/88)
In article <1403@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: (Lots of unecessary text removed) >In article <3117@cbmvax.UUCP>, schein@cbmvax.UUCP (Dan Schein CATS) writes: >> In article <1368@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >> >OK. Let's get this straight. I wasn't flaming Manx, I was flaming you. > >OK. Let's get this straight... > >> > >> >The problem is with disk errors. > >> I think you could have been just a bit clearer on your original posting. >> I very seldom ever use floppies for anything but storage. I use VDK: (RRD) >> to do my work in, that may be why I never noticed the problems your having. > >Before I hit you over the head with a copy of the ROM Kernel manual, would >you like to explain why that's relevent? > I dont think that hitting me will solve your problems, but your welcomed to give it a try. Now that the foolish shit is out of the way, on to the real issue at hand: I feel its relevent because your original posting complained of a problem when trying to save the file when exiting 'Z' by using the 'ZZ' option. It later turned out your problem (complaint) is actually with DOS and not with 'Z' at all. You edit & save to disk where I edit & save to VDK: and that (my book bashing freind) is why all of this is relevent. >-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Dan Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein Commodore AMIGA ARPANET: cbmvax!schein@uunet.uu.net 1200 Wilson Drive Bix: dschein Plink: Dan*CATS West Chester PA 19380 phone: (215) 431-9100 ext. 9542 +----------------------------------------------------------------------------+ All spelling mistakes are a result of my efforts to avoid education :-) +----------------------------------------------------------------------------+ I help Commodore by supporting the AMIGA. Commodore supports me by allowing me to form my own suggestions and comments.
john13@garfield.UUCP (John Russell) (01/19/88)
In article <1403@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >It could happen anywhere, and it's equally annoying >wherever it happens. You can cut things down by not writing to floppies that >often, but the problem remains. Eventually it's going to bite you. You may have drive problems. Since I had my external drive fixed last year I've had ZERO disk problems that weren't due to defective disks, and very few defective disks. When my drive was acting up I was very antsy about writing to disks in it, but now I backup my files to disk at every opportunity. >The problem is that (1) the Amiga is very susceptible to disk errors, and (2) >that the file system should NOT abort writing a file just because it gets >a disk error. Correct me if I'm wrong, I've seen Shell carry out disk operations where it hits a bad block and if you retry it keeps going until the files are copied. You wind up with all files good and usually you never hit the bad block on the disk again. Does it actually do this or might it just be writing into marginal sectors? John -- "A Chinese soldier in Tibet who tried to tear off a British woman's Sergeant Bilko T-shirt has become the first known case of someone mistaking Phil Silvers for the Dalai Lama." -- Toronto Globe & Mail, Nov. 14/87
peter@nuchat.UUCP (Peter da Silva) (01/31/88)
(hits self over head with RKM (Exec... Libraries & Devices is TOO painful)) Let's forget about VI, ZZ, and saving to disk, OK? In article <3157@cbmvax.UUCP>, schein@cbmvax.UUCP (Dan Schein CATS) writes: > It later turned out your problem (complaint) is actually with DOS > and not with 'Z' at all. You edit & save to disk where I edit & save to VDK: > and that (my book bashing freind) is why all of this is relevent. Yes. My complaint is with DOS. VI was an example. In Zen terms, you were looking at the finger when I was pointing at the moon. You really ought to look into Zen. It's educational. Anyway, I was trying for a bit of humor, OK? The problem is that AmigaDOS is not very reliable. Part of the problem is the (insert expletive of choice) one-sector per track arrangement. Yes, I know there are 11 "sectors" per track. They're purely a software effect. From the point of view of the hardware it's one sector. I don't claim to know all the details of why it's not reliable, but I'd like to just ask one thing... Are you doing anything about the 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*.
schein@cbmvax.UUCP (Dan Schein CATS) (02/02/88)
In article <608@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > >The problem is that AmigaDOS is not very reliable. Part of the problem is the > >I don't claim to know all the details of why it's not reliable, but I'd like >to just ask one thing... > >Are you doing anything about the problem? Well fixing AmigaDOS was on my schedule here for January. But I got side tracked into a "Z", AmigaDOS, book bashing with this guy, and well the time that I had alloted for fixing DOS has now expired. Darn! Lets see here..... I start Zen classes in March.... I think I can schedule it in for somewhere around Nov. of 1990..... Yea thats open! :-) :-) :-) :-) >-- >-- 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*. -- Dan Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein Commodore AMIGA ARPANET: cbmvax!schein@uunet.uu.net 1200 Wilson Drive Bix: dschein Plink: Dan*CATS West Chester PA 19380 phone: (215) 431-9100 ext. 9542 +----------------------------------------------------------------------------+ All spelling mistakes are a result of my efforts to avoid education :-) +----------------------------------------------------------------------------+ I help Commodore by supporting the AMIGA. Commodore supports me by allowing me to form my own suggestions and comments.