🚀 go-pugleaf

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 ]