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
maloff@calgary.UUCP (Sheldon Maloff) (06/09/88)
I've just moved this thread over to .tech rather than cross post, since it seems technical enough. In article <3932@cbmvax.UUCP>, steveb@cbmvax.UUCP (Steve Beats) writes: > 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 ? > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [excess deleted...] > > Steve How difficult could this be? I mean specifically key out of range. When this happened to me almost always the disk window pops up and then I get the requester. If a key is out of range couldn't you simply ABORT whatever you are doing. For instance leave the window up, tell me that the key is out of range, let me get rid of the requester, under the smart assumption that the disk is bad and with a good enough error message I could use a disk editor to fix it, or somehow salvage the disk. (of course, provide a salvager program as standard equipment (the Apollo's do)). Of course it may be more serious if this happens while a program is loading, but could the loading simply be stopped? If possible, unload the code that was loaded and free up space, otherwise leave the memory allocated, and let *me* reboot when *I* choose too. My problem is I consider a disk and file system sacred. If there is an error in the system every possible chance should be given to recovery of the system sanity. If the problem can be trapped, then catch it and deal with it. Granted there is eventually somepoint where recovery cannot be made, guru then and only then. But don't simply say, "oopsy, troubled waters, GURU!" I'm somewhat curious (comes from being naive about the Amiga file system) just what all the problems are. Why don't we toss some of them back and forth over the net and get the problem fixed right for a future release? Why don't we start with some of the problems of key out of range? Looking forward to a good discussion. Sheldon. || 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! -= \\ ---==||
peter@sugar.UUCP (Peter da Silva) (06/12/88)
In article ... maloff@calgary.UUCP (Sheldon Maloff) writes: > I've just moved this thread over to .tech rather than cross post, since > it seems technical enough. > In article <3932@cbmvax.UUCP>, steveb@cbmvax.UUCP (Steve Beats) writes: > > In article ... maloff@calgary.UUCP (Sheldon Maloff) writes: > > > 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. Damn straight. > > The current version of FFS has the same code... Are you planning on fixing this? Soon I hope? > > I could go on for ages about how difficult it is to trap errors like > > that, and then exit gracefully. But you've already trapped the error when you go to the guru. > > Exactly what do you do when the data coming off disk are bad ? Return an error code, and let the program clean up. You feel like going over problems in the file system again? We could get into things like bad block handling and baroque directories, too. Hey, I have an idea! How about an alternate file system for Amy: the UFS (UNIX style file system). Have it emulate Examine and ExNext for compatibility, but provide Berkeley-style directory-reading entry points for speed. Take advantage of the last 16 or so years of AT&Ts and Berkeley's work. Yeh. As an aside: I've been re-reading Bach's book and thinking about running UNIX tasks under AmigaDOS. You know, I think it would be dead-easy [*]. You'd need an MMU, but you'd turn the MMU off whenever you left UNIX mode (interrupt while in UNIX task, system call). The MMU overhead would be about zip with just one task (since you wouldn't ever be switching UNIX contexts). To AmigaDOS the UNIX task would look like another Amy task, but with traps to gracefully kill it if it gets out of bounds. You'd have to modify the Exec, some. Not that much. Just provide an entry point whereby a task requests the MMU, and a few entry points to track what the task does with the MMU. Then whenever it goes into that task it'll set the MMU up the way it was when that task left it. If the task had turned it off (say, it was in a system call) then it leaves it off. You could boot up with the UFS, so Amy tasks wouldn't know. AmigaDOS and any AmigaDOS tasks would look like a real-time kernel to UNIX. Of course if you got a guru, you'd be dead, but UNIX tasks wouldn't guru. And with the MMU support, you could even write AmigaDOS tasks with appropriate traps. Turn the MMU on and off whenever you want to deal with MEMF_PUBLIC. Not totally safe, but better than nothing... NewExamine(lock, fib) BPTR lock; struct FileInfoBlock *fib; { struct FileInfoBlock *real_fib; MMU(0); if(!(real_fib = AllocMem(sizeof *fib, MEMF_PUBLIC))) { return 0; } if(!(Examine(lock, real_fib))) { FreeMem(real_fib, sizeof *fib); return 0; } *fib = *real_fib; FreeMem(real_fib, sizeof *fib); MMU(1); return 1; } ---------- [*] Dead-easy is a relative term, here. Compared to supporting AmigaDOS under UNIX it would be. -- -- 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.
toebes@sas.UUCP (John Toebes) (06/13/88)
In article <1663@vaxb.calgary.UUCP> maloff@calgary.UUCP (Sheldon Maloff) writes: >In article <3932@cbmvax.UUCP>, steveb@cbmvax.UUCP (Steve Beats) writes: >> 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. >> > >> Exactly what do you do when the data coming off disk are bad ? >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Steve > >How difficult could this be? I mean specifically key out of range. When >this happened to me almost always the disk window pops up and then I get the >requester. If a key is out of range couldn't you simply ABORT whatever you >are doing. > >My problem is I consider a disk and file system sacred. If there is an >error in the system every possible chance should be given to recovery >of the system sanity. If the problem can be trapped, then catch it and >deal with it. Granted there is eventually somepoint where recovery >cannot be made, guru then and only then. But don't simply say, "oopsy, >troubled waters, GURU!" > >I'm somewhat curious (comes from being naive about the Amiga file system) >just what all the problems are. Why don't we toss >some of them back and forth over the net and get the problem fixed right >for a future release? Why don't we start with some of the problems of >key out of range? > >Looking forward to a good discussion. One of the best suggestions I can make about being able to discuss this issue is to attempt to write a file system. I have spent the past months working on a file handler that is 1.2 compatible (currently working). it is amazing how many of the same problems I have run into as exist in the current handler. There is really only one OBVIOUS intelligent way to write the code. Because of the structure of the file system (which incidently is quite sound) you are dependent upon keys to get you from one place to another. If a particular key is out of range, what do you do? Let us look at the situations that immediately come to mind: 1) Reading a file - simple just return an I/O error to the program attempting to do the read and fire up the validator (again). 2) Writing a file - this is an absolute disaster since the handler just created all the keys. This DOES OCCUR if you pop a diskette while writing. The file system attempts to handle this with the 'You MUST...' requester, but it is no guarentee. Think about how you would have to program if at any time a variable you just set were changed without you getting notification... Of course we could solve this by revalidating the entire disk every time you pop it. There are implications about open files that you REALLY DON'T want to get into now. Trust me. 3) Searching a directory - If the key is out of range then there is reasonable doubt that this is even a directory block (or at lease a valid one). In all likely hood, attempting to continue will result in quite a disaster of infinite looping through the disk trying to walk the directory. Of course you could revalidate the disk but what if you were in the middle of a RENAME operation? As you can see, there is a central theme to this solution. You must be able to refire the validator (intelligently) and respect what it says. But what do you do if you were writing a file and the validator decided the disk was bogus? This is a last ditch situation already, oh, I know, let's fire off the validator to clean it up.. (oh, we just did that). I too long for a good solution and am working hard to find reasonable ones, but the only way to do it is with experimentation and truely understanding all the situations. Please, take the time to research the issues first. There is no substitute to understanding the subject before 'batting around a few ideas'. There are a lot of theoretical approaches to the problem but few will have real applicability to the problem. There are just too many factors involved. |_o_o|\\ John A. Toebes, VIII usenet:..mcnc!rti!sas!toebes |. o.| || | . | || Coordinator of ... | o | || The Software Distillery | . |// USnail: 235 Trillingham Ln, Cary NC 27513 ====== BBS: (919)-471-6436
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.
peter@sugar.UUCP (Peter da Silva) (06/15/88)
In article <7541@swan.ulowell.edu>, page@swan.ulowell.edu (Bob Page) writes: > I wrote: > > 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. > peter@sugar.UUCP (Peter da Silva) replied: > >Bob, that's misleading. ... Once you mount the disk successfully, > >UNIX will stay up even in the face of *rampant* disk corruption > No way. Look at the source code. Love to. Will you email me a copy? :-> > The 4.3 file system has at least 49 > system panics (read: crashes) alone. Duplicate inodes, freeing free > blocks/inodes/frags, corrupted bitmaps, block reads that return zero > bytes, corrupted cache, and run-of-the-mill things like linked > directories and lost directory entries. We get some of those things fairly often in our environment without crashing. Of course we don't have the good fortune to have the latest and greatest Berkeley product... just 30 intel boxes running that bastard Xenix and a couple of SYSV machines. Also, at least some of those problems are not attributable to defective media: corrupted caches, for example. Finally, UNIX is much more dependent on disks than AmigaDOS. Are you sure that some of those panics aren't restricted to the root partition? > My point is ... UNIX is not the answer to everything. No, it's abominably poor at real-time work. It does do a better job than AmigaDOS of dealing with defective media, though. It recognises that it exists. -- -- 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.
kent@xanth.cs.odu.edu (Kent Paul Dolan) (06/16/88)
In article <2120@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: [???] >In article ... kent@xanth.cs.odu.edu (Kent Paul Dolan) writes: >> In article <2108@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >> >As an aside: I've been re-reading Bach's book and thinking about >> >running UNIX tasks under AmigaDOS.... > >> >The MMU overhead would be about zip with just one task (since you >> >wouldn't ever be switching UNIX contexts). > >> Huh? I frequently spawn 16 or 20 tasks to run in background >> under BSD 4.3, (not during business hours and survive, but at >> 3 AM...) ... > >If you're on an Amiga you're running at least 16 or 20 tasks: Intuition, >console windows, all your open devices, all your programs, etc... Remember >the diagram at the front of all the RKMs. > You sort of ignored the point here, Peter. We weren't talking about AmigaDOS tasks, we were talking about Unix. You said Unix wouldn't be wasting time swapping tasks, and I demurred. Picture a demon unix power user who bought her new Amiga because it was the most cost effective Unix box on the block. She has code to design and deadlines to meet, so she's going to learn AmigaDOS as time allows, but she is going to expect to come in and run Unix right out of the box, and get her work done. She bought the system, after all, to port her knowledge easily to new hardware; otherwise she'd be looking harder at OS/MTdiv2 (if the multitasking version ever hits the streets), or MacMultiFinder. Don't tell her she can only run one Unix task at a time, or that is the last Amiga sale in her circle of acquaintance. >> switching among with the extremely easy ^Z, %<job-number> job >> control of 4.3 BSD. > >I'll take Intuition any day. If you don't like mice, just load up wKeys >and hit your own window select routine. So will I, but I know how to use it; that isn't the buyer AmiIX is aimed at; why bother preaching to the converted? >> I suppose I'm missing something here, but >> if I'm coming to this machine as a power Unix user, I expect >> this stuff to work on AmiIX too, > >It will, just as well as on your 68020 UNIX... that is considerably less >well than an equal number of AmigaDOS processes. Sure, since AmigaDOS does tasks and processes. Still not the point; your statement was: The MMU overhead would be about zip with just one task (since you wouldn't ever be switching UNIX contexts). I hope that is not what gets designed; it won't sell a second Amiga. >> and I'll pick up on that >> strange AmigaDOS thingie as time allows. What have I missed? > >What you've missed is that AmigaDOS has way less overhead than UNIX, so >on a given peice of iron you're going to get way better response time under >AmigaDOS. The overhead I'm talking about is the UNIX task-switching. You >don't need UNIX task overhead for getty, init, and all the other trusted >programs. And what I described wasn't the system facilities that always run in background, but little fiascos like spawning twenty shars or ten sendmails of eleven letters each all at once (both of which I've done within the last month; the sendmails were an accident, how was I to know a script with ten commands in a row was going to drop them all into the background for asynchronous processing? The script had no internal "&"'s, so I expected them to run one by one. The system came to a pretty good imitation of flash frozen for about three minutes until all those letters were waiting in spool files, and of course this was the middle of the afternoon.) Lots and lots of times I will background a couple of zoo's while I check on the success of another, or edit a cover letter; that is just normal Unix use. There's _lots_ of Unix task switching going on, among application level tasks, even if I'm the only user online. >> >To AmigaDOS the UNIX task would look like another Amy task, but with >> >traps to gracefully kill it if it gets out of bounds. > >> This "bounds" is going to be a nice entity; scatter load the >> Unix process, > >Why scatter-load the UNIX process? Change contexts, look at an AmigaDOS power user who wants to use Unix just every once in a while. I might be several hours into my work day when I decide to bring up Unix, and I don't have checkpointing built into my stray cycle eating ray tracer, so I expect to come up in the existing memory fragmentation, not have to reboot. Why would you design any process running under AmigaDOS, least of all something as big as AmiIX, to not scatter load? All the docs say the opposite. >> and have a few Amiga processes acquiring and >> releasing memory, as Unix jobs malloc and free, and find an >> easy way to describe the boundary. ;-) > >UNIX jobs never shrink, you know. I suppose we could do UNIX one better here >and use AllocMem and FreeMem, but there's really no point in improving on >that. You can allocate memory to the UNIX process however you like. If it >gets too fragmented it, you can always shuffle it around. You can even have >it demand paged. If you really want to go nutso, you can assign a big chunk >of memory to UNIX (like, all but 512K or so) and use UNIX memory management >inside it. There are lots of solutions to these problems. Does "Unix jobs never shrink" mean "free" is a scam? This really doesn't affect the argument, though, because even if all Unix does is add memory, with AmigaDOS adding and freeing memory, the Unix portion will share some of the complexity of spagetti. Of course, if you have a huge superabundance of memory, you can always just give the Unix process the top half, but we have seen at least one reverse of the memory cost curve trend, so maybe we should plan on less than superabundant memory; and design for the "must use efficiently and well" case instead. >> Kent, the man from xanth. > >Kent, do you have to be so negative all the time? How about engaging in some >constructive criticism. Suggest alternative methods for doing things. Try to >keep important facts (like the relative performance of UNIX and the Amiga >EXEC) in mind. Just what purpose are you trying to serve here? Well, I've seen a lot of projects start off with this "piece of cake" attitude, and get killed off when they started eating up much more time and money than projected. Poking Unix in as a process under AmigaDOS has a lot of attractive features, and might well turn out to be a good idea, but requirements specs are supposed to be conservatively scoped out so management gets as few nasty shocks as possible. You don't get that kind of analysis if everybody plays Pollyanna. I happen to be of a conservative nature, so it is my natural part to question unproved feasibility; whether in the end my worries prove true or false, they serve a useful purpose in the early going. Sorry if you don't like having to defend your ideas. I guess I should just let you rattle on uninterrupted. Kent, the man from xanth.
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
mat@emcard.UUCP (Mat Waites) (06/17/88)
In article <5597@xanth.cs.odu.edu> kent@cs.odu.edu (Kent Paul Dolan) writes: > > Does "Unix jobs never shrink" mean "free" is a scam? This really > doesn't affect the argument, though, .... > ... >Kent, the man from xanth. The malloc() / free() implementations I've worked with never shrink. malloc() calls a lower level memory allocation routine to allocate chunks of memory. These chunks are often much larger than what was requested, but malloc returns you a pointer to a piece the size you asked for. On your next malloc call, there could possibly be enough memory still around from the first chunk to immediately return your malloc'ed bit of memory. When you free(), the malloc'ed memory is returned to a LOCAL pool of memory available for future malloc'ing. It doesn't return to the system until your process exits. (hey, Unix was just written by a couple of guys foolin' around. What can you expect?) Mat -- W Mat Waites | PHONE: (404) 727-7197 Emory Univ Cardiac Data Bank | UUCP: ...!gatech!emcard!mat Atlanta, GA 30322 |
maloff@calgary.UUCP (Sheldon Maloff) (06/18/88)
In article <552@sas.UUCP>, toebes@sas.UUCP (John Toebes) writes: > In article <1663@vaxb.calgary.UUCP> maloff@calgary.UUCP (Sheldon Maloff) writes: > >In article <3932@cbmvax.UUCP>, steveb@cbmvax.UUCP (Steve Beats) writes: > >> 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. > >> > > >> Exactly what do you do when the data coming off disk are bad ? > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> Steve > > > >How difficult could this be? I mean specifically key out of range. When > >this happened to me almost always the disk window pops up and then I get the > > One of the best suggestions I can make about being able to discuss this issue > is to attempt to write a file system. I have spent the past months working Uh Uh, can't do. Have to much time devoted to my job. I'll have to let the pro's of the Amiga deal with this. > Because of the structure of the file system (which incidently is quite sound) No doubt here. I beleive it just by running disksalv on a trashed disk. Recovery of nearly every file. > 1) Reading a file - simple just return an I/O error to the program attempting > to do the read and fire up the validator (again). Fire up the validator. And if it can't do anything with the disk, give me a requester saying the disk is bad. Let me take it out of the drive, and I'll fix it at a later date, but don't GURU on me. > 2) Writing a file - this is an absolute disaster since the handler just > created all the keys. This DOES OCCUR if you pop a diskette while > writing. The file system attempts to handle this with the 'You MUST...' I'm not worried about popping a disk. That YOU MUST... requester is good, and I've seen it a few times, but usually only while I popped the disk when there was a pause in the write, and I thought it was done. I've never trashed a disk this way. I HAVE trashed when I popped while a write was in progress, but again, a good requester like "you fool! you just made me trash a disk." Abort the write, let me pop it in again and try to read it. Now were back at case 1. No GURU's! > 3) Searching a directory - If the key is out of range then there is reasonable > doubt that this is even a directory block (or at lease a valid one). Give me a requester saying "Possibly not a directory, can't properly read disk, use disksalv". Don't GURU. > As you can see, there is a central theme to this solution. You must be able > to refire the validator (intelligently) and respect what it says. But what > do you do if you were writing a file and the validator decided the disk was > bogus? This is a last ditch situation already, oh, I know, let's fire off the > validator to clean it up.. (oh, we just did that). I too long for a good Fire the validator once. Respect what it says. After that, let me get the damn disk out of my drive. The system does not have to lose its sanity because of *my*, *a user*, error. A good informational requester. I'll fix the disk on my own time, when I don't have 5 or 6 other *important tasks* running. > Please, take the time to research the issues first. There is no substitute to > understanding the subject before 'batting around a few ideas'. There are a I program for a living. I research issues, for *my job*. At home I'm a USER. A plain joe with a computer. It is not the responsiblity of the USER to research things looked at by programmers, and tossed off as, "...Boy I Can't deal with that, I'll just guru." You've noticed the error, state it, get the disk out of the drive, and live on. Provide a good disksalv utility as standard. Give it good documentation, so that the average joe can, when he wants to sacrifice his system to insanity, try and recover the disk. > |_o_o|\\ John A. Toebes, VIII usenet:..mcnc!rti!sas!toebes || 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! -= \\ ---==||
melnik@topaz.rutgers.edu (Ofer Melnik) (06/19/88)
Can someone send me a copy of Disksalv (it is PD, right?) Thanks Ofer Melnik