maloff@calgary.UUCP (Sheldon Maloff) (06/04/88)
I've had this happen to me a few times now, and I'm beginning to get annoyed. I have this disk here. I put it in the machine and its icon appears. I double click on its icon and its window opens up. And then I get a visit from a system requester: Disk Corrupt - Task Held Finish ALL Disk Activity etc. I select cancel, and GOMF (Get Outta My Face 1.0) doesn't appear, instead I go straight into a guru of this form 8700000B.265F48F1 So I look up in my handy Amiga-Guru book on what this means and I find out we have a fatal error in the dos library, specifically key out of range. What piece of code, where, is so stupid as to require a guru just because I've selected on a corrupt disk? It wears my faith a little for a machine that cannot even recover from a corrupt disk. Could somebody please tell me what's happening here. Suffice it to say there are many ways to corrupt a disk, I want to know why the machine CANNOT ALWAYS recover from a corrupt disk. Thanx. || Sheldon ----========== \\ -----======|| || maloff@calgary.UUCP -----====== // Calgary, Alberta || || {ihnp4!alberta}!calgary!maloff -----== \\ Past Host of the || || .. eventually, we'll all be scaled by zero and ---= // '88 Winter Games || || converge upon the origin ... then we'll party! -= \\ ---==||
steveb@cbmvax.UUCP (Steve Beats) (06/06/88)
In article <1657@vaxb.calgary.UUCP> maloff@calgary.UUCP (Sheldon Maloff) writes: >I've had this happen to me a few times now, and I'm beginning to get annoyed. > > Disk Corrupt - Task Held > Finish ALL Disk Activity > etc. > >I go straight into a guru of this form > > 8700000B.265F48F1 > >So I look up in my handy Amiga-Guru book on what this means and I find >out we have a fatal error in the dos library, specifically key out of range. > Yeah, I know! This should really be considered an 'A' bug (one which should be fixed before release) but it hasn't been. The current version of FFS has the same code, and will guru on you if a file or directory header contains a reference to a key outside the partition (or floppy) bounds. I could go on for ages about how difficult it is to trap errors like that, and then exit gracefully. Exactly what do you do when the data coming off disk are bad ? But I won't! Suffice to say, that for the 1.4 release, when FFS is in ROM and supporting old (slow FS) format, these guru's will dissappear forever. I'm planning to put a little more information into the requesters that will tell the user which file has the error (if it was a file) and what error code was returned from the driver. I'd also like to add an extra gadget, IGNORE, so that files containing bad sectors can at least be partially read. What the hell. Does anyone out there have suggestions for improvement on the file system error handling? I mean JUST error handling, OK. I'm not planning to change the functionality of the file system to any large degree, though there will be a few 'extras' in there. Oh yeah, any and all comments about the file system having bad block handling will be summarily ignored :-) Steve
peter@sugar.UUCP (Peter da Silva) (06/14/88)
In article <7416@swan.ulowell.edu>, page@swan.ulowell.edu (Bob Page) writes: > Oh, in case you think this is just an AmigaDOSism ... here's a line > from the UNIX (4BSD) man page for mount(1): > Mounting file systems full of garbage will crash the system. Bob, that's misleading. Yes, the Amiga handles disks that are full of garbage a whole lot better than UNIX. On the other hand, we're talking of disks that are just slightly damaged. Once you mount the disk successfully, UNIX will stay up even in the face of *rampant* disk corruption (ever try looking at a 35 sector disk with a 36 sector filesystem on it). It's just not at all reasonable to treat a bad block number as a fatal (guru-style) disk error. Print a message on the console or put up a requestor saying the disk is corrupted. Then you can fsck or diskdoctor or disksalv it. Return an I/O error code to the program. But guru? No. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These may be the official opinions of Hackercorp.
mwm@eris.berkeley.edu (Mike (I'm in love with my car) Meyer) (06/14/88)
In article <2115@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:
<Bob, that's misleading. Yes, the Amiga handles disks that are full of
<garbage a whole lot better than UNIX. On the other hand, we're talking
<of disks that are just slightly damaged. Once you mount the disk
<successfully, UNIX will stay up even in the face of *rampant* disk
<corruption
But Unix when it was several times older than AmigaDOS is now had
those kinds of problems; Berkeley and AT&T (and thousands of hackers
around the world) have been beating on the Unix file system(s), and
fixing those things since the early '70s. Even as late as 1980,
running out of space on a file system could panic a Unix.
Even now, the validator & diskdocter do well by fsck -p standards, and
disksalve is something that just flat doesn't exist. Nuts - Unix got to
v6 (or was it v7) without having tools for fixing broken file systems.
Unless you think adb and clri qualify.
True, AmigaDOS is still a bit paranoid about things. I want a system
like VMS, that will run with the disks drives smoking, cables not
properly plugged in and the system pack and swap areas write
protected. I suspect that AmigaDOS will get there before any Unix
does.
<mike
--
Must have walked those streets for hours, Mike Meyer
In the dark and in the cold, mwm@berkeley.edu
Before I really could accept, ucbvax!mwm
There's no place called hope road. mwm@ucbjade.BITNETdale@boing.UUCP (Dale Luck) (06/15/88)
In article <2115@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > Once you mount the disk >successfully, UNIX will stay up even in the face of *rampant* disk >corruption (ever try looking at a 35 sector disk with a 36 sector >filesystem on it). That's funny when my unix system sun/3.0 tries to free a afree inode the result is not pleasant. Same thing with free block list. Or what happens if /etc/init has disappeared? >-- > But guru? How about 'panic: freeing free inode' What the amiga needs is an fsck utility that fixes the disk without you needing to be a filesystem guru and edit the disk it self. The result from fsck should be a disk that is correct, none of this " copy files to a new disk and reformat" bs. >-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Dale Luck Boing, Inc. Although I do contract work for Amiga-LosGatos, my opinions probably don't represent those of Commodore or its management or its engineers, but I think the world would be a better place if they did.
doug-merritt@cup.portal.com (06/16/88)
Mike Meyer wrote: > Nuts - Unix got to >v6 (or was it v7) without having tools for fixing broken file systems. >Unless you think adb and clri qualify. We used "diddlei", which was a minimal binary debugger that understood inode structures, letting us read/write at will to different inodes. Not fsdb nor even fsck but better than nothing. This was v6 Unix. But come to think of it, I don't think it was part of the standard release... pretty sure that Jeff Schriebman wrote it locally (at Berkeley). Doug -- Doug Merritt ucbvax!sun.com!cup.portal.com!doug-merritt or ucbvax!eris!doug (doug@eris.berkeley.edu) or ucbvax!unisoft!certes!doug