mrush@ecst.csuchico.edu (Matt "C P." Rush) (11/28/90)
In article <1990Nov25.093445.10710@evax.arl.utexas.edu> hill@evax.arl.utexas.edu (Adam Hill) writes: > > He did tell me two good things: > >Don't EVER use media that has not been mapped. >Don't EVER fill a CBM hd >95% full.. Why? He did not go in depth. WHY IS THIS??? I've been bitten by this a couple of times now. I've got a SeaGate ST157-N (ya, I know, SeaGate sucks) running on a Pacific Peripherals Overdrive controller. When this thing gets anywhere over 97% full, I start getting "Volume Overdrive has a Read/Write Error...." messages just from trying to READ a file (using 'more', or 'type'). If this didn't happen on files that were good BEFORE the drive reached 97% full, and didn't go away when the drive had more room on it, I'd say there was a problem on the media. But that ain't it. AmigaDOS just doesn't like full hard drives, and enquiring minds are little curious as to WHY? Could some CBM guru shed a little light on this, or at least say it's been fixed in 2.x...? -- Matt *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* % "I programmed three days % Beam me up, Scotty. % % And heard no human voices. % There's no Artificial % % But the hard disk sang." % Intelligence down here. % % -- Yoshiko % % E-mail: mrush@cscihp.ecst.csuchico.edu % *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* This is a SCHOOL! Do you think they even CARE about MY opinions?!
DXB132@psuvm.psu.edu (11/28/90)
Sorry I can't help your problem, but I can say that I personally haven't had any trouble filling up my 2090/ST251. In fact, I get a "disk full" message at least once a week (hoping to get an 80MB drive 'soon'...I need it desperately!). There's only one thing to watch out for. Some versions of the fast file system have a bug that makes it impossible to recover from a "disk full" condition (by deleting some files and clicking on 'retry'). If you try to do that you'll be greeted by the Guru... So perhaps it's a result of buggy/inadaquate host drivers or drive firmware rather than AmigaDOS that is causing your serious problem. -- Dan Babcock
thad@cup.portal.com (Thad P Floryan) (11/28/90)
mrush@ecst.csuchico.edu (Matt "C P." Rush) in <1990Nov27.223354.25258@ecst.csuchico.edu> writes: In article <1990Nov25.093445.10710@evax.arl.utexas.edu> hill@evax.arl.utexas.edu (Adam Hill) writes: > > He did tell me two good things: > >Don't EVER use media that has not been mapped. >Don't EVER fill a CBM hd >95% full.. Why? He did not go in depth. WHY IS THIS??? I've been bitten by this a couple of times now. I've got a SeaGate ST157-N (ya, I know, SeaGate sucks) running on a Pacific Peripherals Overdrive controller. When this thing gets anywhere over 97% full, I start getting "Volume Overdrive has a Read/Write Error...." messages just from trying to READ a file (using 'more', or 'type'). If this didn't happen on files that were good BEFORE the drive reached 97% full, and didn't go away when the drive had more room on it, I'd say there was a problem on the media. But that ain't it. AmigaDOS just doesn't like full hard drives, and enquiring minds are little curious as to WHY? Could some CBM guru shed a little light on this, or at least say it's been fixed in 2.x...? If it ain't broke, DON'T fix it. Someone's feeding you a load of bushwa, and you CAN bet on that. The comment about the Seagate drive, though, IS true! :-) Let's just take a look at my home Amiga's HD configuration: CLI6> info v Mounted Disks: Unit Size Used Free Full Errs Status Name DH61: 45M 88577 1742 98% 0 Read/Write SYS6B DH60: 45M 83535 8093 91% 0 Read/Write SYS6A DH50: 302M 313402 291486 51% 0 Read/Write SYS5 DH40: 47M 93995 851 99% 0 Read/Write SYS4 DH24: 26M 53239 9 99% 0 Read/Write SYS2E DH23: 50M 101243 5 99% 0 Read/Write SYS2D DH22: 50M 95764 5484 94% 0 Read/Write SYS2C DH21: 50M 100712 536 99% 0 Read/Write SYS2B DH20: 50M 76442 24806 75% 0 Read/Write SYS2A DF2: No disk present DF1: No disk present RAM: 373K 745 0 100% 0 Read/Write RamDisk DF0: 880K 813 945 46% 0 Read Only SupraBoot CLI6> lastboot System last booted Sun 8-Jul-1990 14:32:15 CLI6> OK, that machine has been running since then with no reboots; it was rebooted then because I had to clean it out after a fire "took out" my kitchen Sunday July 1 and deposited soot over everything (and I mean EVERYTHING). Look at the entry for DH40: (aka SYS4); that's an ST-157N. Look at the entries for DH24: and DH23: ... those are partitions on a Maxtor. I've run my drives down to ZERO free blocks with NO problems whatsoever; this is with Supra's software and AmigaDOS 1.3.2 on an A1000 having: CLI6> cpu The CPU is a 68020 with a 68881 The video is NTSC and system clocking is from a GenLock CLI6> avail Type Size In-Use Available Largest chip 515,864 246,584 269,280 268,336 fast 8,388,568 1,773,968 6,614,600 3,532,344 $C00 0 0 0 0 >16M 0 0 0 0 total 8,904,432 2,020,552 6,883,880 CLI6> Everything works just fine. The ONLY problem I've had is the ^$%#& Seagate ST-157N on this system with its non-spin stiction. At this time I only put games and anims on that drive since I would NEVER trust a Seagate drive for any valuable data ... but as long as it's spinning it does "work." Due to my own early experiences operating a computer at home, I believe it MANDATORY for proper surge and transient suppression to be used on one's system. Back when I first got the Amigas (mid-1985), I was operating without such protection and would get 3 to 5 "fatal" floppy errors a week due to refrigerator kicking in, turning on flourescent lamps, operating drill motors, and even powering a modem ON/OFF. When I "got smart" and added surge and UPS protection around early 1986, I haven't had a SINGLE floppy error or any HD errors after HDs became available for the Amiga. Of course, it's also possible your Pacific Peripherals Overdrive setup is flawed, but I know nuttin' 'bout 'dat and can offer no further suggestions. Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
peter@sugar.hackercorp.com (Peter da Silva) (11/28/90)
In article <1990Nov27.223354.25258@ecst.csuchico.edu> mrush@ecst.csuchico.edu (Matt "C P." Rush) writes: > Could some CBM guru shed a little light on this, or at least say it's > been fixed in 2.x...? Seems to be. I've filled up partitions several times with no problem. (and that 50 MB quantum seemed SO big when I started...) -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
stephane@Chucla.CAM.ORG (Stephane Laroche) (11/29/90)
In article <1990Nov27.223354.25258@ecst.csuchico.edu>, Matt "C P." Rush writes: > In article <1990Nov25.093445.10710@evax.arl.utexas.edu> hill@evax.arl.utexas.edu (Adam Hill) writes: > > > > He did tell me two good things: > > > >Don't EVER use media that has not been mapped. > >Don't EVER fill a CBM hd >95% full.. Why? He did not go in depth. > > WHY IS THIS??? I've been bitten by this a couple of times now. I've > got a SeaGate ST157-N (ya, I know, SeaGate sucks) running on a Pacific > Peripherals Overdrive controller. > When this thing gets anywhere over 97% full, I start getting "Volume > Overdrive has a Read/Write Error...." messages just from trying to READ a file > (using 'more', or 'type'). > > If this didn't happen on files that were good BEFORE the drive reached > 97% full, and didn't go away when the drive had more room on it, I'd say there > was a problem on the media. But that ain't it. AmigaDOS just doesn't like full > hard drives, and enquiring minds are little curious as to WHY? > > Could some CBM guru shed a little light on this, or at least say it's > been fixed in 2.x...? How can you say it's AmigaDos fault? As far as I'm concerned, it could be the controller or even the drive (in the case of a SCSI drive). I've been using a Seagate ST-251 40M hard disk for 2 years now and it has been most of the time oscillating between 95% and 100% full. The controller is a 2090a and I'm using a 2000 with AmigaDos 1.3. NOTE: I moved this discussion to comp.sys.amiga.hardware. > -- Matt Stephane Laroche | Email: stephane@Chucla.CAM.ORG +1 514 277-8605 | Montreal, Que., Canada
blgardne@javelin.es.com (Blaine Gardner) (11/29/90)
mrush@ecst.csuchico.edu (Matt "C P." Rush) writes: >In article <1990Nov25.093445.10710@evax.arl.utexas.edu> hill@evax.arl.utexas.edu (Adam Hill) writes: >>Don't EVER fill a CBM hd >95% full.. Why? He did not go in depth. > When this thing gets anywhere over 97% full, I start getting "Volume >Overdrive has a Read/Write Error...." messages just from trying to READ a file >(using 'more', or 'type'). It sounds to me like you've told the system that the hard drive is a little bigger than it actually is. I've had no problem at all when one of my 70 meg partitions was 100% full, either on the Hardframe on the 2000/2500 or on the A3000 controller. For a simple test of your drive, get Fred Fish's FillDisk program (on one of the older disks), and run it on your hard drive. FillDisk simply opens a file, and starts writing to it until the disk fills up. Fred intended it to clobber any deleted files that you might not want someone else undeleting, but it does make a handy disk tester. If FillDisk starts reporting I/O errors at 97% full, I'd suggest backing up your drive, reformatting it with a few fewer cylinders, and running FillDisk again. If you get no errors the second time, you've found the problem. This worked fine for me when I wanted to verify that the fake floppies I'd created by juggling mountlist entries did not overlap any other partitions. -- Blaine Gardner @ Evans & Sutherland 580 Arapeen Drive, SLC, Utah 84108 blgardne@esunix.UUCP BIX: blaine_g {decwrl, utah-cs}!esunix!blgardne PLink: BlaineG DoD #0046 My other motorcycle is a Quadracer.
phil@adam.adelaide.edu.au (Phil Kernick) (11/29/90)
Before everyone with hard drives says that YOU CAN FILL THEM COMPLETELY
FULL. Ask yourself the following question:
What version of l:fastfilesystem am I using?
I remember *AGES* ago, this exact same thread, and yes, if you had a
hard-drive formatted with the original (1.3) fastfilesystem you would
get crashed on the hard-drive if it was filled to more than about 95%.
This was a known bug, and was fixed in the 1.3.2 release.
If you have the problem, and it is the ffs problem, then upgrade the
system software and it will go away. If it is your hard-drive device
driver then that is a completely different thing...
Phil.
--
Phil Kernick EMail: phil@adam.adelaide.edu.au
Departmental Engineer Phone: +618 228 5914
Dept. of Psychology Fax: +618 224 0464
University of Adelaide Mail: GPO Box 498 Adelaide SA 5001rooijen@rulcvx.LeidenUniv.nl (A.J. van Rooijen) (11/29/90)
In article <36302@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: > CLI6> lastboot > System last booted Sun 8-Jul-1990 14:32:15 What kind of software are you running capable of avoiding guru's since 8 july?? I should like to know that. I have a guru at least one time a day on my A500. And I don't even have a 68020 board. Erwin van Breemen
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (11/30/90)
In <1057@rulcvx.LeidenUniv.nl>, rooijen@rulcvx.LeidenUniv.nl (A.J. van Rooijen) writes: >In article <36302@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >> CLI6> lastboot >> System last booted Sun 8-Jul-1990 14:32:15 > >What kind of software are you running capable of avoiding guru's since 8 july?? >I should like to know that. I have a guru at least one time a day on my A500. >And I don't even have a 68020 board. Maybe you should get a 68020 board. :-) Seriously, I am running a lot of standard and non-standard stuff, and if it wasn't for the programming I do, I would probably only reboot once every few months. Check around and see what you are running that is giving you problems. If you can't find anything that might be causing it, you might want to have your power supply checked. -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
dtiberio@libws3.ic.sunysb.edu (David Tiberio) (11/30/90)
I have had problems with a full 880k disk! Don't believe me? Take a workbench and stuff it with files as best as possible. Then try to open a shell. It will not open the shell on mine, so I assume that some programs write to the disk for some reason and need a little space. Maybe 5k is enough for a floppy. :)
aliu@aludra.usc.edu (Alex C. Liu) (11/30/90)
In article <1990Nov29.191350.2273@sbcs.sunysb.edu> dtiberio@libws3.ic.sunysb.edu (David Tiberio) writes: >I have had problems with a full 880k disk! Don't believe me? Take a workbench >and stuff it with files as best as possible. Then try to open a shell. It will >not open the shell on mine, so I assume that some programs write to the disk >for some reason and need a little space. Maybe 5k is enough for a floppy. :) Well, I noticed that ALL AmigaDOS scripts creates temp file in T:. Since the startup-sequence is also a script, then it must write into your Boot disk when first starting up the machine. (This is even before you get a chance to assign T: to RAM:) In order words, you can fill you Disk up to 100% if and only if you are sure that you are not going to boot from that disk.
new@ee.udel.edu (Darren New) (11/30/90)
In article <13383@chaph.usc.edu> aliu@aludra.usc.edu (Alex C. Liu) writes: >Well, I noticed that ALL AmigaDOS scripts creates temp file in T:. Only if there is a .key directive (or if there is a nested execute, maybe?) >Since the startup-sequence is also a script, then it must write into >your Boot disk when first starting up the machine. Shame on you! You don't boot off a write-protected floppy? :-) -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- =+=+=+ Let GROPE be an N-tuple where ... +=+=+=
peter@cbmvax.commodore.com (Peter Cherna) (11/30/90)
In article <13383@chaph.usc.edu> aliu@aludra.usc.edu (Alex C. Liu) writes: >Well, I noticed that ALL AmigaDOS scripts creates temp file in T:. >Since the startup-sequence is also a script, then it must write into >your Boot disk when first starting up the machine. (This is even >before you get a chance to assign T: to RAM:) This is incorrect. Execute only creates a temp file if it thinks that some parameter substitution (angle brackets, or .bra and .ket replacements) are involved. The initial startup-sequence cannot have parameter substitution, so no temp file is created when you boot a disk. Recall that if T: is not yet assigned, execute tries to use :T. If a temp file was created, you could never boot off a write-protected disk! >In order words, you can fill you Disk up to 100% if and only if you >are sure that you are not going to boot from that disk. Not so. Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. I have found a proof for Fermat's theorem, but there is no room in the .sig!
thad@cup.portal.com (Thad P Floryan) (11/30/90)
rooijen@rulcvx.LeidenUniv.nl (A.J. van Rooijen) in <1057@rulcvx.LeidenUniv.nl> asks: >In article <36302@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >> CLI6> lastboot >> System last booted Sun 8-Jul-1990 14:32:15 > >What kind of software are you running capable of avoiding guru's since 8 july? ? >I should like to know that. I have a guru at least one time a day on my A500. >And I don't even have a 68020 board. > >Erwin van Breemen Fair question, deserving an answer: essentially either software I trust or software I've written myself. And I use the Amiga system(s) VERY heavily. I have one at home and two in my office (yeah, actually in MY office on MY desk) Editing: mg2a (micro-Emacs, Mike Meyers' version) Telecomm: handshake 2.12a for talking to my DEC-20s, VAXes, UNIX boxes, etc., in fact, for everything except when I need to do "online" file transfers using zmodem at which time I switch to AZCOMM 1.00 only for the time required to do the zmodem'ing, then back to Handshake. Takes but a few seconds to switch back-'n-forth. Actually, I usually "batch up" file transfer requests until I'm just about ready to go to sleep for the day, then switch to AZCOMM and enter "sz -b * ; exit" on the UNIX box(es) then click-on zmodem receive; the next morning I change back to Handshake. Been doing this for a l-o-n-g time and it works fine. Compiling: Manx (mostly) and Lattice. Also Absoft Fortran. Also several cross-assemblers I've written for use on some of my outside consulting jobs. I burn EPROMs directly off the Amiga using Handshake talking to an International Microsystems EPROM-1 box; in fact, I have 8 devices connected to a serial port switcher: several modems, a StarLAN NAU, HP plotter, C.Itoh ProWriter, and lines to serial ports on several UNIX boxes. Text processing: AmigaTeX by Tom Rokicki (and source files prepared either using mg2a on the Amiga or "imported" from elsewhere). I use this heavily for nearly all documentation, newsletters, flyers, users' group agendas, etc. Also WordPerfect for compatibility with docs I either receive from elsewhere or must send elsewhere. PC Layout and CAD: Pro-Net and Pro-Board. Aegis Draw+ PLOT: device and some misc. other Misc Utilities: Conman, PopColours, POPCLI (aka Mackie from Tom Rokicki, though I've changed its name), cp (Jeff Lydiatt's), ls (from the net), many "net" replacements for various AmigaDOS "commands" (all for which I have the source), my "info" and "avail", sweep, tar, compress, uuencode and uudecode, unshar, cal, appt, etc etc etc for about several 1000's of programs in my c:, util:, and other directories. Many of these go back to 1985 and 1986 (yep, they STILL work under the latest OS). Note that I've source for nearly ALL of them, many from "Fish Disks", since I often add customizations. I could do an "ls -lR" of the directories in my PATH, but that would be wasteful. Games: shanghai, Test Drive II (which, by the way, is "real time" and DOES return back to the CLI upon completion, leaving everything intact, showing that it IS possible to have fun, interactive games which are hard disk installable and do things "right" (even though their other games don't)), asteriods (sic), and some 50+ other programs in my "games:" directory Misc: DPaint II, DigiView (for doing photos documenting other things, as people who saw my Hard Drive lecture at FAUG may remember), various "show" and "anim" displays, etc etc For your reference, a listing of the ASSIGNS, PATH, environmental vars, and stack size is appended; I didn't want to clutter up this part of my post. The point being: if one abides the "rules" as printed ever since the first DevCon back in May 1985 in Monterey, there is NO reason for one to be seeing gurus on one's machine unless there's an actual HARDWARE failure. If you ARE seeing gurus, then the software you're running is GARBAGE and should be tossed out and your money-back demanded. Getting on a "small" soapbox here, my biggest gripe with most so-called "commercial" software available for the Amiga is that most of it is, in general, well conceived but poorly designed and implemented. People simply do NOT design and/or code properly nor do they perform even rudimentary QA. When I see some mfrs ship "updates" nearly weekly, I wonder why they cannot get it right the first time. If the methods used to teach and practice CS were applied to, say, civil engineering or EE or to the medical profession, there probably wouldn't be anyone alive in the world today. In fact, this is a big problem I see with most CS courses as taught today: people are NOT being taught how to DESIGN software. CS classes "should" be structured along the lines of the EE, CS, etc. disciplines. Note lack of smileys above. I've been in the computer software/hardware business for about 25 years; prior to that I was doing architectural design, and also microwave receiver design for gov't applications, and I also designed and operated a microwave IC fab plant (sheesh, I was "doing" GaAs ICs, YAG and YIG, on diamond and sapphire substrates a l-o-n-g time ago), so I have much experience with QA and design "up-front." Some of that paid off for a contract I had with JPL about 20 years ago to "prove" the tenets of structured software design. It DOES work! I immediately applied the results of that JPL contract to another system I designed start-finish for real-time monitoring of light water nuclear reactors. Several hundred of those were built and are STILL being sold with my original software unchanged ... if it ain't broke, DON'T fix it; and a minor mod to that software is (was?) being used to monitor stress in the cables on the Golden Gate bridge. Then the AMPS system (Automated MicroProbe System; a computerized scanning electron microscope). Then the POINT (POlice INTelligence) system; for this I had to first design/implement a new language which, in retrospect, resembles "C" (for "C" wasn't readily available back then). These systems are 100% reliable and failsafe. Also, my company and I pioneered "structured QA" of software projects way back when no-one even considered this possible; this includes both regression and comprehensive testing. And all these techniques WORK and assure reliable (and non-GURU :-) functioning software systems. It's MY belief, and borne out by JPL and many, many others for whom I've done software, that a software project should be: 90% design up front 5% coding time 5% QA and checkout With a structured design (either flowcharts or using my DLT processor (i.e. a flowchart compiler)), the design can then be coded in whatever language one chooses. Most of my earlier programs were 100% assembler (due to machine memory constraints), but they could just as easily have been coded in, say, Fortran, BASIC, COBOL, whatever, from the same structured design and would have operated the same (albeit more slowly in some cases). And many of these were NOT trivial programs; one of the largest comprised some 750,000 lines of assembly code, which I then converted to C about 5-6 years ago, enhanced further during the past 5 years, and am now porting to UNIX. And the nature of that code includes complete 4GL DBMS processing and my parsers, code gen (yep, for speed, I generate 100% machine code for all users' queries and programs), runside libraries, etc etc etc. I apply the same techniques to all software I write, and THAT's why I'm able to keep my Amigas (and other systems) up so long. I will NOT tolerate "crap" software whose every execution paths were not tested or verified ... which is also why I oftimes have to write my own stuff since I don't trust most of the commercial software out there. Software should be DESIGNED along the same techniques which are used for other engineering disciplines ... sadly, that's seldom the case in the real world. And that's why you see your GURUs and the like. :-( {end of soapbox} Hope some of this provides some insights and food for thought. I didn't mean to be so long-winded on what "could" have been a short answer to Erwin's question as to why my Amiga(s) stay up so long between reboots. I felt some of my thoughts and the issues mentioned in these regards ARE pertinent to this technical newsgroup. Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ] -------------------- begin included material -------------------- Perhaps the following may give you more insight to my systems' configs; most my Amigas are similar in these regards. And I *DO* have separately-purchased and licensed copies of the commercial software, so don't waste time even suggesting that I am running "illegal" multiple copies; many who frequented the Amiga BBS systems on which I was the SYSOP know my position on software piracy. CLI6> assign Volumes: RamDisk [Mounted] SYS6B [Mounted] SYS6A [Mounted] SYS5 [Mounted] SYS4 [Mounted] SYS2E [Mounted] SYS2D [Mounted] SYS2C [Mounted] SYS2B [Mounted] SYS2A [Mounted] SupraBoot [Mounted] Directories: C RamDisk:C GAMES SYS4:GAMES FontPath SYS2A:AmigaTeX/TeX/pk LaTeX SYS2A:AmigaTeX/TeX TeXfiles SYS2A:AmigaTeX/TeX TeX SYS2A:AmigaTeX/TeX WP SYS6A:WP VS3D SYS6A:VideoScape-3D UTIL SYS6A:UTILITIES UDICT SYS6A:Dictionaries TBasic SYS6A:True_Basic SRC SYS6A:Sources SCRIBBLE SYS6A:Scribble ProW SYS6A:ProWrite Print SYS6A:WP PCLO SYS6A:PCLO PAGE SYS6A:PageSetter OLD SYS6A:OLD NEW SYS6A:NEW MVP SYS6A:MVP-Forth MODULA2 SYS6A:Modula2 MISC SYS6A:MISC META SYS6A:Debuggers/MetaScope LINT SYS6A:LINT LIBR SYS6A:LIBRARIES Learn SYS6A:WP/learn LANG SYS6A:LANGUAGES JForth SYS6A:JForth IFF SYS6A:IFF_Tools INCL SYS6A:Include HELP SYS6A:HELP EXPL SYS6A:Debuggers/EXPLORER DV SYS6A:DigiView DRAW SYS6A:DrawPlus DOCS SYS6A:Documentation DICT SYS6A:Dictionaries DEBUG SYS6A:Debuggers DCad SYS6A:DynamiCad DBMS SYS6A:DBMS COPIERS SYS6A:COPIERS CONT SYS6A:CONTENTS COMM SYS6A:TELECOMM CC SYS6A:AZTEC BBS SYS6A:BBS AUTO SYS6A:AutoDOCS w3 RamDisk:w3 w2 RamDisk:w2 w1 RamDisk:w1 ul RamDisk:ul dl RamDisk:dl ww RamDisk:ww t RamDisk:T l SYS6A:l s SYS6A:s SYSTEM SYS6A:System DEVS SYS6A:devs FONTS SYS6A:fonts LIBS SYS6A:libs TBA SYS2C:PORTAL-MAIL-TO-BE-ANSWERED PDL SYS2C:portal JC SYS2C:BBS-JC Files.db SYS2C:Files.db DL3 SYS2E:DL3 DL2 SYS2E:DL2 DL1 SYS2E:DL1 ANIMS SYS4:ANIMS SYS SYS6A: Devices: DH61 DH60 DH50 DH40 DH24 DH23 DH22 DH21 DH20 DF2 DF1 PRT PAR SER RAW CON RAM DF0 CLI6> path show Current directory RamDisk:C SYS6A:LANGUAGES SYS6A:UTILITIES SYS6A:TELECOMM SYS6A: SYS6A:System SYS6A:AZTEC C: CLI6 set CLIB=CC:LIB/ INCLUDE=CC:INCLUDE!CC:ASM CCTEMP=RAM: TZ=PST8PDT CLI6> stack current stack size is 70000 bytes CLI6> -------------------- end of included material --------------------
dewolfe@ug.cs.dal.ca (Anarchy for Peace) (12/01/90)
In article <phil.659837272@adam.adelaide.edu.au> phil@adam.adelaide.edu.au (Phil Kernick) writes: >I remember *AGES* ago, this exact same thread, and yes, if you had a >hard-drive formatted with the original (1.3) fastfilesystem you would >get crashed on the hard-drive if it was filled to more than about 95%. > > >Phil. Never happened to me... I had a Quantum 80S hooked to a Hardframe in my 2000 and was constantly hovering around 88-89% full. Even had a couple of "Volume Full" requestors appear, no r/w errors though. This was with the original 1.3. I never heard of 1.3.2 until I got my 3000. > >-- >Phil Kernick EMail: phil@adam.adelaide.edu.au >Departmental Engineer Phone: +618 228 5914 >Dept. of Psychology Fax: +618 224 0464 >University of Adelaide Mail: GPO Box 498 Adelaide SA 5001 Colin DeWolfe dewolfe@ug.cs.dal.ca dewolfe@iris1.ucis.dal.ca
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/01/90)
In <13383@chaph.usc.edu>, aliu@aludra.usc.edu (Alex C. Liu) writes: >In article <1990Nov29.191350.2273@sbcs.sunysb.edu> dtiberio@libws3.ic.sunysb.edu (David Tiberio) writes: >>I have had problems with a full 880k disk! Don't believe me? Take a workbench >>and stuff it with files as best as possible. Then try to open a shell. It will >>not open the shell on mine, so I assume that some programs write to the disk >>for some reason and need a little space. Maybe 5k is enough for a floppy. :) > >Well, I noticed that ALL AmigaDOS scripts creates temp file in T:. >Since the startup-sequence is also a script, then it must write into >your Boot disk when first starting up the machine. (This is even >before you get a chance to assign T: to RAM:) All Amigados scripts do not create a temp file. A temp file is created under certain conditions. One of those is when another 'execute' is kicked off from a script. You can avoid the temp file generated by excuting another script by executing it using a 'NewCLI' or 'NewShell', with the FROM keyword naming the script you are starting. >In order words, you can fill you Disk up to 100% if and only if you >are sure that you are not going to boot from that disk. The only thing to watch for is the temp file, and that you make sure you have assigned T: to somewhere else before it gets created. -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jap@convex.cl.msu.edu (Joe Porkka) (12/02/90)
hclausen@adspdk.UUCP (Henrik Clausen) writes: >In article <1990Nov27.223354.25258@ecst.csuchico.edu>, Matt "C P." Rush writes: >> In article <1990Nov25.093445.10710@evax.arl.utexas.edu> hill@evax.arl.utexas.edu (Adam Hill) writes: >> > >> > He did tell me two good things: >> > >> >Don't EVER fill a CBM hd >95% full.. Why? He did not go in depth. >> >> If this didn't happen on files that were good BEFORE the drive reached >> 97% full, and didn't go away when the drive had more room on it, I'd say there >> was a problem on the media. But that ain't it. AmigaDOS just doesn't like full >> hard drives, and enquiring minds are little curious as to WHY? I just did a little scientific test. I have a A590 with 6.0 roms. 20 meg drive, partitioned into 2 equal size 10 meg partitions. They are 21058 block each. I had dh1: at about 93%. I just attempted to fill it to 21059 blocks via C:JOIN. I got a requester "Disk Full", I hit cancel, join aborted and left the destination file as was. Now, dh1: is 100%full, and NoProblems. One time I did fill the disk, as originally shipped it was a single 20meg partition. It ended up being corrupted, but I think the cause was a brain dead program - it did not check for errors - it just kept hitting its head against "Disk Full" requests - I had to reboot - and BOOM the disk was Invalidatable - but I didn't lose anything (after backup/restore).
jap@convex.cl.msu.edu (Joe Porkka) (12/02/90)
thad@cup.portal.com (Thad P Floryan) writes:
Hey Thad, you shuould try HandShake when there is not enough
memory for it to run. It does not behave well.
I stopped using it awhile ago becuase of that (And i dont have 8megs!),
since it would frequently either crash or not free memory
when I was trying to fire it up with other stuff going.thad@cup.portal.com (Thad P Floryan) (12/02/90)
jap@convex.cl.msu.edu (Joe Porkka) in <1990Dec1.194656.8074@msuinfo.cl.msu.edu>
writes:
Hey Thad, you shuould try HandShake when there is not enough
memory for it to run. It does not behave well.
'Tis possible. I'm not about to test that failure-mode on my system, not
after having endured "only" 512K RAM back in 1985 and since I don't have
an MMU on my Amigas for memory/process protection.
For that matter, even the mg2a I use has some serious flaws, the most
obnoxious being an apparent use of 16-bit ints for defining the boundaries
of a region. Just read in, say, a 100K file, and attempt to delete more
than 64K from the text buffer after having set the "mark" and using ^W.
Yet it's also able to handle 1MB+ files just fine in other instances. I
haven't bothered to look into the problem since Mike has a new beta version
out and since I have the "real" Stallman EMACS running on my DEC-20, VAX,
and UNIX systems.
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]bscott@isis.cs.du.edu (Ben Scott) (12/06/90)
In article <1990Nov27.223354.25258@ecst.csuchico.edu> mrush@ecst.csuchico.edu (Matt "C P." Rush) writes: >In article <1990Nov25.093445.10710@evax.arl.utexas.edu> hill@evax.arl.utexas.edu (Adam Hill) writes: >>Don't EVER fill a CBM hd >95% full.. Why? He did not go in depth. > > WHY IS THIS??? I've been bitten by this a couple of times now. I've >got a SeaGate ST157-N (ya, I know, SeaGate sucks) running on a Pacific >Peripherals Overdrive controller. > When this thing gets anywhere over 97% full, I start getting "Volume >Overdrive has a Read/Write Error...." messages just from trying to READ a file >(using 'more', or 'type'). I've heard about this "problem" from time to time but have never had it happen to me. At least, I don't think so. I have a stock (populated) A-590 and due to the despicable reality of having to live in 21 megs (only for a few more weeks now, though!!) it is generally almost totally full. In fact quite often I spend days with less than 50K free. I've done this since a month or two after I got it and I got it almost a year ago. I've never had any problems (not absolutely tracable to a different cause) until recently and they, while mysterious of origin, occured when I actually had more free space than I've had for some time. Of course, it may be that this is the great, fantastic, beautiful and capable A-590 at work, but I've heard that it's actually a problem in the FFS (which I use). So, who knows? BTW, additional notes while I'm here - any important replies (hah!) should go in Email as we're only getting a fraction of news right now due to a blockage somewhere in uunet. Second, if Blaine Gardner is reading this, I can NOT reach you no way, no how, and I tried at least 8 DIFFERENT routings. Your mail seems to reach me fine but I cannot reply. I still want to sell you those keyboards. Please send me an alternate location to reach you or something. . <<<<Infinite K>>>> -- |Ben Scott, professional goof-off and consultant at The Raster Image, Denver| |FIDO point address 1:104/421.2, bscott@isis.cs.du.edu, or BBS (303)424-9831| |"Spent 4 hours burying the cat!" "Four || The Raster Image IS responsible | | hours?!?" "It wouldn't keep still..." || for everything I say! | *Amiga* |