rg20+@andrew.cmu.edu (Rick Francis Golembiewski) (01/02/91)
I was testing out a program that wrote out a file to disk, in any case the program was stuck in an infinate loop, so I was forced to do a reboot, and now I get: Volume HardDisk has a checksum error on disk block 27030 And thus my main partition (92MB) is unable to validate. Is there any way that I can resolve this error without a reformat? (Since it will take ~90 disks to back it up and I don't have that many right now...). I ran HDToolbox and did a verify data on the drive, it reported no errors, but I cannot get amigaDOS to verify that partition, So I can't write to or delete from that partition (VERY annonying). Any help would be greatly appreciated. // Rick Golembiewski rg20+@andrew.cmu.edu \\ \\ #include stddisclaimer.h // \\ "I never respected a man who could spell" // \\ -M. Twain //
thad@cup.portal.com (Thad P Floryan) (01/02/91)
rg20+@andrew.cmu.edu (Rick Francis Golembiewski)
in <cbUFsB200VIFFNxVlN@andrew.cmu.edu> writes:
I was testing out a program that wrote out a file to disk, in any case
the program was stuck in an infinate loop, so I was forced to do a
reboot, and now I get: Volume HardDisk has a checksum error on disk
block 27030
And thus my main partition (92MB) is unable to validate. Is there any
way that I can resolve this error without a reformat?
[...]
With all due sympathy for Rick's problem, the fragility of the Amiga file
system is one of the primary reasons I didn't bother renewing my "Developer"
status last year and stopped developing commercial software for the Amiga.
[The advent of SVR4 on the Amiga will, of course, change my opinion. :-) ]
I hope, for everyone's sake, the problems have been fixed in 2.*
Nowadays, I develop new software on UNIX where it's "safe" to do so, and I
port the occasional program over to my Amigas. If you think Rick has a
problem with 92MB, mine would be over 10 times more severe if I had that kind
of trouble occur to my HD during development; definitely NOT worth the hassle
for something that shouldn't be occurring in the first place.
Without a doubt, the things that are needed for the Amiga (and from CBM as
officially supported tools) include:
1. equivalent to UNIX's "fsck"
2. equivalent to UNIX's "fsdb"
3. easy and convenient (ideally automatic) bad-block mapping while
online (SCSI *can* do this automatically in case you were unaware)
4. SCSI tools along the lines of those found at "adaptex" by Roy Neese
(of Adaptec) for the MS-DOS world ... these tools are simply
incredible. If you want to grab them, I've included an extract
from my /usr/lib/uucp/Systems for you to uucp them yourself.
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
-------------------- begin included material --------------------
# Roy Neese
# Adaptec Central Field Applications Engineer
# UUCP @ {texbell,attctc}!cpe!adaptex!neese
# merch!adaptex!neese
# uunet!swbatl!texbell!merch!adaptex!neese
#
# adaptex cycles from 9600->2400->1200->9600->...
#
# To get any of the files, use:
#
# uucp adaptex!~/file /usr/spool/uucppublic/file
# or uucp adaptex!/usr/spool/uucppublic/scsiutil/file ~/file
#
# The detailed list and descr of what is on adaptex is the "list" file.
#
adaptex Wk2310-0730,Sa,Su ACU0 2400 18174886893 "" \d\d\d gin:-BREAK\d\d\d-gin:
-BREAK\d\d\d-gin: suucp
-------------------- end included material --------------------jdickson@jato.jpl.nasa.gov (Jeff Dickson) (01/03/91)
In article <37492@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >rg20+@andrew.cmu.edu (Rick Francis Golembiewski) >in <cbUFsB200VIFFNxVlN@andrew.cmu.edu> writes: > > I was testing out a program that wrote out a file to disk, in any case > the program was stuck in an infinate loop, so I was forced to do a > reboot, and now I get: Volume HardDisk has a checksum error on disk > block 27030 > > And thus my main partition (92MB) is unable to validate. Is there any > way that I can resolve this error without a reformat? > [...] > >With all due sympathy for Rick's problem, the fragility of the Amiga file >system is one of the primary reasons I didn't bother renewing my "Developer" >status last year and stopped developing commercial software for the Amiga. >[The advent of SVR4 on the Amiga will, of course, change my opinion. :-) ] > >I hope, for everyone's sake, the problems have been fixed in 2.* > >Nowadays, I develop new software on UNIX where it's "safe" to do so, and I >port the occasional program over to my Amigas. If you think Rick has a >problem with 92MB, mine would be over 10 times more severe if I had that kind >of trouble occur to my HD during development; definitely NOT worth the hassle >for something that shouldn't be occurring in the first place. > >Without a doubt, the things that are needed for the Amiga (and from CBM as >officially supported tools) include: > > 1. equivalent to UNIX's "fsck" > 2. equivalent to UNIX's "fsdb" > 3. easy and convenient (ideally automatic) bad-block mapping while > online (SCSI *can* do this automatically in case you were unaware) > 4. SCSI tools along the lines of those found at "adaptex" by Roy Neese > (of Adaptec) for the MS-DOS world ... these tools are simply > incredible. If you want to grab them, I've included an extract > from my /usr/lib/uucp/Systems for you to uucp them yourself. > >Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ] > >-------------------- begin included material -------------------- > ># Roy Neese ># Adaptec Central Field Applications Engineer ># UUCP @ {texbell,attctc}!cpe!adaptex!neese ># merch!adaptex!neese ># uunet!swbatl!texbell!merch!adaptex!neese ># ># adaptex cycles from 9600->2400->1200->9600->... ># ># To get any of the files, use: ># ># uucp adaptex!~/file /usr/spool/uucppublic/file ># or uucp adaptex!/usr/spool/uucppublic/scsiutil/file ~/file ># ># The detailed list and descr of what is on adaptex is the "list" file. ># >adaptex Wk2310-0730,Sa,Su ACU0 2400 18174886893 "" \d\d\d gin:-BREAK\d\d\d-gin: >-BREAK\d\d\d-gin: suucp > >-------------------- end included material -------------------- Newsgroups: comp.sys.amiga,comp.sys.amiga.tech Subject: Re: HD Errors Summary: Expires: References: <cbUFsB200VIFFNxVlN@andrew.cmu.edu> <37492@cup.portal.com> Sender: Reply-To: jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) Followup-To: Distribution: Organization: Jet Propulsion Laboratory, Pasadena, CA Keywords: In article <37492@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >rg20+@andrew.cmu.edu (Rick Francis Golembiewski) >in <cbUFsB200VIFFNxVlN@andrew.cmu.edu> writes: > > I was testing out a program that wrote out a file to disk, in any case > the program was stuck in an infinate loop, so I was forced to do a > reboot, and now I get: Volume HardDisk has a checksum error on disk > block 27030 > > And thus my main partition (92MB) is unable to validate. Is there any > way that I can resolve this error without a reformat? > [...] > >With all due sympathy for Rick's problem, the fragility of the Amiga file >system is one of the primary reasons I didn't bother renewing my "Developer" >status last year and stopped developing commercial software for the Amiga. >[The advent of SVR4 on the Amiga will, of course, change my opinion. :-) ] > >I hope, for everyone's sake, the problems have been fixed in 2.* I made the mistake one time of rebooting the machine while a berserk program wrote non-stop to a file on my hard drive. I had to reformat. But then a disk can be corrupted by doing this on most any system. It'd be nice if C= would include some fsck program, but that they haven't isn't going to deter my interest from programming the Amiga. The meek possibility of this happening stresses the importance of backups. Jeff
tll@nntp-server.caltech.edu (Tal Lewis Lancaster) (01/03/91)
rg20+@andrew.cmu.edu (Rick Francis Golembiewski) writes: >I was testing out a program that wrote out a file to disk, in any case >the program was stuck in an infinate loop, so I was forced to do a >reboot, and now I get: >Volume HardDisk has a checksum error on disk block 27030 >And thus my main partition (92MB) is unable to validate. Is there any >way that I can resolve this error without a reformat? This has happened to me several times in the past week. I ran ran the AMIGADos DiskDoctor on the hard drive. The bad news is that the file name that you were writting to may still show up in the FAT and it will stay there until you need to reformat to remove it. I am sure the is a utility out there to patch that area. I would try this as a only as a last resort. Tal.
hessmann@unipas.fmi.uni-passau.de (Georg Hessmann) (01/03/91)
In article <1991Jan2.190655.15790@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: |In article <37492@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: |>rg20+@andrew.cmu.edu (Rick Francis Golembiewski) |>in <cbUFsB200VIFFNxVlN@andrew.cmu.edu> writes: |> |> I was testing out a program that wrote out a file to disk, in any case |> the program was stuck in an infinate loop, so I was forced to do a |> reboot, and now I get: Volume HardDisk has a checksum error on disk |> block 27030 |> |> And thus my main partition (92MB) is unable to validate. Is there any |> way that I can resolve this error without a reformat? |> [...] |> |>With all due sympathy for Rick's problem, the fragility of the Amiga file |>system is one of the primary reasons I didn't bother renewing my "Developer" |>status last year and stopped developing commercial software for the Amiga. |>[The advent of SVR4 on the Amiga will, of course, change my opinion. :-) ] |> |>I hope, for everyone's sake, the problems have been fixed in 2.* | | I made the mistake one time of rebooting the machine while a berserk |program wrote non-stop to a file on my hard drive. I had to reformat. But |then a disk can be corrupted by doing this on most any system. First, I don't think so (UN*X fsck deletes the file and all is ok). Second, if really all other systems has such an bad feature is this no reason that the Amiga OS have this too. | It'd be nice if C= would include some fsck program, but that they |haven't isn't going to deter my interest from programming the Amiga. The |meek possibility of this happening stresses the importance of backups. But Backup/Restore of a big partition is very anoying. Yesterday a program open two files and boots the machine. Now my hard disk is validating. But I won't format my disk! I don't have lost any data (I still can read the disk), but backup format and restore is not very nice. Diskdoctor don't help and disksalv need's another disk :-(( | Jeff Georg. -- hessmann@unipas.fmi.uni-passau.de hessmann@unipas.uucp
thad@cup.portal.com (Thad P Floryan) (01/03/91)
jdickson@jato.jpl.nasa.gov (Jeff Dickson)
in <1991Jan2.190655.15790@jato.jpl.nasa.gov> writes:
I made the mistake one time of rebooting the machine while a berserk
program wrote non-stop to a file on my hard drive. I had to reformat.
But then a disk can be corrupted by doing this on most any system.
Perhaps. But I've never had that problem with UNIX. Absolute worst case was
when *I* screwed something up badly while testing, so just reached around and
hit the reset button, and in 5 minutes the system was back up fine, bad files
were repaired, and I continued (literally) as if nothing had happened; having
process memory protection (e.g. an MMU) with UNIX also helps!
If you want some advice, NEVER, EVER test a "new" program to/from/on a HD.
Always use RAM: (or whatever else you find suitable).
It'd be nice if C= would include some fsck program, but that they
haven't isn't going to deter my interest from programming the Amiga.
The meek possibility of this happening stresses the importance of
backups.
No question about backups! :-) Attached is something I posted to another
newgroup last year that you may find interesting/amusing.
As for my comment re: "my stopping commercial development", that was mostly a
marketing decision due to the nature of most the software I write (4GL DBMS
products, language compilers, and products based on computational linguistics
and natural language processing by automata) simply being priced out of what
is presently perceived as "the Amiga marketplace." We (my company) are making
the switch to UNIX and when SVR4 becomes available on an Amiga platform we'll
(probably again) embrace the Amiga. At present my products are on what are
termed "mainframes" and "super minis."
I personally still write a LOT of stuff for ol' Ami, and there's even some of
my stuff floating around on Fish Disks, archive sites, and elsewhere.
I still feel "strongly" about the fragility of the Amiga filesystem. Just
reading the Usenet newsgroups, an inordinate disproportionate share of HD
errors (requiring reformatting and reloading) seem to plague ONLY the Amiga.
Of the thousand or so comp.sys.amiga.* articles still unexpired here, I can
probably find well over a hundred lamenting serious HD problems. Contrast
that scenario with my attachment (below).
Thad
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
-------------------- begin attachment
Seems that with all the other issues and activities recently, I neglected to
post a followup to my query "Ascertaining a file name given a HD block
number."
The solution is actually quite straightforward:
Brant Cheikes' program ``bf'' (block find, version 1.3, available at
the osu-cis archive site) returns the inode(s) of files given the
physical block number, and
either "ncheck" or "find -inum # -print" will return the filepath/name
given the inode number.
In my recent situation I again "lucked out" since the block I spared belonged
to an *.o file, so "nothing" was lost.
During the past several years I've only had two blocks "go bad" amongst some 8
systems and have never lost anything.
Which brings me to my favorite exhortations (as many have heard before at
various users' groups meetings here in Silicon Valley) and transcribed from
recordings made at some of the meetings:
`` Hard drives WILL fail; the only uncertainty is when, but it is
guaranteed they WILL fail.
All things mechanical, be they switches, connectors, sockets, cables,
or rotating memories, will wear out or self-destruct at the most
inopportune time in accordance with Murphy's Law and its corollaries.
Your only defense is to develop a system backup regimen and abide it.
The one day you neglect your {sysadmin | operator} duty is the day
your most-valued data develops software rot and bit decay.
And let us not also forget the most dangerous command on the {insert
favorite system name here} is the carriage return; examine what you
have entered BEFORE flailing away at the RETURN key as most commands
are NOT retractable.
...
''daveh@cbmvax.commodore.com (Dave Haynie) (01/04/91)
In article <1991Jan3.141624.25450@forwiss.uni-passau.de> hessmann@unipas.fmi.uni-passau.de (Georg Hessmann) writes: >In article <1991Jan2.190655.15790@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >First, I don't think so (UN*X fsck deletes the file and all is ok). >Second, if really all other systems has such an bad feature is this no reason >that the Amiga OS have this too. >| It'd be nice if C= would include some fsck program, but that they >|haven't isn't going to deter my interest from programming the Amiga. The >|meek possibility of this happening stresses the importance of backups. >Diskdoctor don't help and disksalv need's another disk :-(( The lesson of DiskDoctor, among other things, is that reconstructing damaged files in-place is very difficult, and sometimes impossible, to do correctly. If your program guesses wrong, you can make the situation worse, not better. The reason programs like fsck delete the offending files, rather than try to repair them, is exactly this. A program like DiskSalv can do more, since it is copying to another disk. For example, assume you have two files linked into the same data somehow. There is no way an fsck type program can give you two safe versions of that file; the best it can do is attempt to determine which of the two files really owns that data and unlink the other from the filesystem. DiskSalv can rebuild both of them, and let the user determine which of the two, if either, is correct. And DiskSalv can't possibly rebuild a file that's not a correct filesystem file, since it uses the actual filesystem to rebuild the files. I think that both types of tools are useful, though the worst tool you can run into is the one that actually causes damage. A real fsck-type program for the Amiga's SFS/FFS isn't all that difficult to do correctly. I think the main problem with such tools is that, so far, everyone who's written them has tried to fix too much in place, and as a result, has had problems with reliability. Judging whether a file can be recovered, in the DiskSalv context, is difficult enough. DiskSalv uses a number of small evaluation functions, which are basically little expect systems, to determine if a file is safe enough to try recovering (a really wacky file could crash the recovery program, and anything too messed up is highly unlikely to have any good stuff in it anyway). Not that DiskSalv V1.42 is the end of the line, either -- I have figured out how to recover a number of errors that neither DS V1.42 nor FixDisk can manage, though there's a great deal of work left before that technology will be ready for popular consumption. >| Jeff -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "Don't worry, 'bout a thing. 'Cause every little thing, gonna be alright" -Bob Marley
pkenny@ADS.COM (Patrick Kenny) (01/04/91)
While on the subject of HD's. Is it advisable to always Park your hard drive when you turn the computer and drive off, or just when you want to move it. Also is there a PD Park out there for SCSI drives on the Amiga. thanks -pk
thad@cup.portal.com (Thad P Floryan) (01/04/91)
pkenny@ADS.COM (Patrick Kenny) in <F^V^MX$@ads.com> writes:
While on the subject of HD's. Is it advisable to always Park your hard
drive when you turn the computer and drive off, or just when you want
to move it. Also is there a PD Park out there for SCSI drives on the
Amiga.
The general answer to the first question would be "Yes." But all modern HDs
are autoparking, meaning they move the heads all the way in towards the
central area of the platter during powerdown; this is especially true for all
SCSI or ESDI drives I've seen (but there's always the possibility of an
exception). But autoparking is so easy to implement using back-EMF from the
rotating platter that it's hard to believe any drive manufactured today doesn't
do it as part of the spindle-braking routine.
Some 3rd party controller/driver mfrs supply a "park" utility, but because
embedded-SCSI drives all seem to autopark there isn't much of a need for an
explicit utility.
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]jdickson@jato.jpl.nasa.gov (Jeff Dickson) (01/04/91)
In article <1991Jan3.141624.25450@forwiss.uni-passau.de> hessmann@unipas.fmi.uni-passau.de (Georg Hessmann) writes: >In article <1991Jan2.190655.15790@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >|In article <37492@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >|>rg20+@andrew.cmu.edu (Rick Francis Golembiewski) >|>in <cbUFsB200VIFFNxVlN@andrew.cmu.edu> writes: >|> >|> I was testing out a program that wrote out a file to disk, in any case >|> the program was stuck in an infinate loop, so I was forced to do a >|> reboot, and now I get: Volume HardDisk has a checksum error on disk >|> block 27030 >|> >|> And thus my main partition (92MB) is unable to validate. Is there any >|> way that I can resolve this error without a reformat? >|> [...] >|> >|>With all due sympathy for Rick's problem, the fragility of the Amiga file >|>system is one of the primary reasons I didn't bother renewing my "Developer" >|>status last year and stopped developing commercial software for the Amiga. >|>[The advent of SVR4 on the Amiga will, of course, change my opinion. :-) ] >|> >|>I hope, for everyone's sake, the problems have been fixed in 2.* >| >| I made the mistake one time of rebooting the machine while a berserk >|program wrote non-stop to a file on my hard drive. I had to reformat. But >|then a disk can be corrupted by doing this on most any system. > >First, I don't think so (UN*X fsck deletes the file and all is ok). >Second, if really all other systems has such an bad feature is this no reason >that the Amiga OS have this too. > >| It'd be nice if C= would include some fsck program, but that they >|haven't isn't going to deter my interest from programming the Amiga. The >|meek possibility of this happening stresses the importance of backups. > >But Backup/Restore of a big partition is very anoying. >Yesterday a program open two files and boots the machine. >Now my hard disk is validating. But I won't format my disk! > >I don't have lost any data (I still can read the disk), but backup >format and restore is not very nice. > >Diskdoctor don't help and disksalv need's another disk :-(( > >| Jeff > > Georg. > >-- > hessmann@unipas.fmi.uni-passau.de hessmann@unipas.uucp Newsgroups: comp.sys.amiga,comp.sys.amiga.tech Subject: Re: HD Errors Summary: Expires: References: <cbUFsB200VIFFNxVlN@andrew.cmu.edu> <37492@cup.portal.com> <1991Jan2.190655.15790@jato.jpl.nasa.gov> <1991Jan3.141624.25450@forwiss.uni-passau.de> Sender: Reply-To: jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) Followup-To: Distribution: Organization: Jet Propulsion Laboratory, Pasadena, CA Keywords: In article <1991Jan3.141624.25450@forwiss.uni-passau.de> hessmann@unipas.fmi.uni-passau.de (Georg Hessmann) writes: >In article <1991Jan2.190655.15790@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >|In article <37492@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >|>rg20+@andrew.cmu.edu (Rick Francis Golembiewski) >|>in <cbUFsB200VIFFNxVlN@andrew.cmu.edu> writes: >|> >|> I was testing out a program that wrote out a file to disk, in any case >|> the program was stuck in an infinate loop, so I was forced to do a >|> reboot, and now I get: Volume HardDisk has a checksum error on disk >|> block 27030 >|> >|> And thus my main partition (92MB) is unable to validate. Is there any >|> way that I can resolve this error without a reformat? >|> [...] >|> >|>With all due sympathy for Rick's problem, the fragility of the Amiga file >|>system is one of the primary reasons I didn't bother renewing my "Developer" >|>status last year and stopped developing commercial software for the Amiga. >|>[The advent of SVR4 on the Amiga will, of course, change my opinion. :-) ] >|> >|>I hope, for everyone's sake, the problems have been fixed in 2.* >| >| I made the mistake one time of rebooting the machine while a berserk >|program wrote non-stop to a file on my hard drive. I had to reformat. But >|then a disk can be corrupted by doing this on most any system. > >First, I don't think so (UN*X fsck deletes the file and all is ok). fsck pieces the file back together from the hopefully usable infor- mation on the disk. If it can't, it will give you the option of deleting it. fsck isn't magically making the file reappear. >Second, if really all other systems has such an bad feature is this no reason >that the Amiga OS have this too. I've heard that C= plans to limit the possibility of corrupting a file system even more in Ver 2.0. Something about updating the disk so as to keep little of it's static state in RAM. After C= implements this, the Amiga's file system will probably fall into this realm you see all other file systems in. > >| It'd be nice if C= would include some fsck program, but that they >|haven't isn't going to deter my interest from programming the Amiga. The >|meek possibility of this happening stresses the importance of backups. > >But Backup/Restore of a big partition is very anoying. >Yesterday a program open two files and boots the machine. >Now my hard disk is validating. But I won't format my disk! Yeah well. When I said backups - I was speaking of just the stuff you are currently working on and stuff you have worked on in the past. My hard disk going berserk does not tickle me pink, but it doesn't cripple me either. > >I don't have lost any data (I still can read the disk), but backup >format and restore is not very nice. > >Diskdoctor don't help and disksalv need's another disk :-(( I agree - Diskdoctor is real laugh. > >| Jeff > > Georg. > >-- > hessmann@unipas.fmi.uni-passau.de hessmann@unipas.uucp jeff
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (01/04/91)
hessmann@unipas.fmi.uni-passau.de (Georg Hessmann) writes: >But Backup/Restore of a big partition is very anoying. >Yesterday a program open two files and boots the machine. >Now my hard disk is validating. But I won't format my disk! >I don't have lost any data (I still can read the disk), but backup >format and restore is not very nice. >Diskdoctor don't help and disksalv need's another disk :-(( Depends on your attitude, mostly. I couldn't afford a backup device when I bought my drive, so the next cheapest think was to use my drive as the restore area, sort of. I still make a copy of _everything_ to floppy, since I know my situation is dangerous. [But I also would prefer never being forced to recover my current environment from my (quite disorganized) floppy files.] But also, I formatted my HD into six partitions, with the last one getting the stray extra cylinders. I never put any thing in my SPARE: partition that can't be nuked at a moment's notice (I tend to unpack and repack big archives there, for instance). This means, the one time I've managed to clobber my PLAY: partition beta testing a buggy game, I just nuked the trash in SPARE: and used disksalv to recover PLAY: onto SPARE: So, at a cost of 1/6th of my HD storage capacity, I have a place to target disksalv, for now. Later, when I can afford a streaming tape drive, I'll start putting keeper stuff in SPARE: and doing nightly backups, but for now my drive is way under half full, and this was a cheap fix. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
telam@pyrps5.pyramid.com (Thomas Elam) (01/04/91)
In article <37492@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >rg20+@andrew.cmu.edu (Rick Francis Golembiewski) >in <cbUFsB200VIFFNxVlN@andrew.cmu.edu> writes: > > [...] > And thus my main partition (92MB) is unable to validate. Is there any > way that I can resolve this error without a reformat? > [...] > >With all due sympathy for Rick's problem, the fragility of the Amiga file >system is one of the primary reasons I didn't bother renewing my "Developer" >status last year and stopped developing commercial software for the Amiga. >[The advent of SVR4 on the Amiga will, of course, change my opinion. :-) ] > >[...] > >Without a doubt, the things that are needed for the Amiga (and from CBM as >officially supported tools) include: > > 1. equivalent to UNIX's "fsck" > 2. equivalent to UNIX's "fsdb" > 3. easy and convenient (ideally automatic) bad-block mapping while > online (SCSI *can* do this automatically in case you were unaware) Thad, how would the file system get involved in the bad-block mapping? > 4. SCSI tools along the lines of those found at "adaptex" by Roy Neese > (of Adaptec) for the MS-DOS world ... these tools are simply > incredible. If you want to grab them, I've included an extract > from my /usr/lib/uucp/Systems for you to uucp them yourself. > >Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ] > >-------------------- begin included material -------------------- > ># Roy Neese ># Adaptec Central Field Applications Engineer ># UUCP @ {texbell,attctc}!cpe!adaptex!neese ># merch!adaptex!neese ># uunet!swbatl!texbell!merch!adaptex!neese ># >[instructions on how to uucp information deleted] For those of us for which ftp is much easier to use than is uucp, how can we get the list and description? For example, could you give us a phone number for voice communication or a postal address? Thanks. Tom
skank@iastate.edu (Skank George L) (01/04/91)
In article <cbUFsB200VIFFNxVlN@andrew.cmu.edu> rg20+@andrew.cmu.edu (Rick Francis Golembiewski) writes: > >I was testing out a program that wrote out a file to disk, in any case >the program was stuck in an infinate loop, so I was forced to do a >reboot, and now I get: >Volume HardDisk has a checksum error on disk block 27030 > >And thus my main partition (92MB) is unable to validate. Is there any >way that I can resolve this error without a reformat? (Since it will >take ~90 disks to back it up and I don't have that many right now...). >I ran HDToolbox and did a verify data on the drive, it reported no >errors, but I cannot get amigaDOS to verify that partition, So I >can't write to or delete from that partition (VERY annonying). Any >help would be greatly appreciated. I experienced a similar problem on my A3000. Eventually I came to the realization that the problem was on the mother board of my machine (I replaced the hard drive and the problem remained). My machine is still (for the last three weeks now) sitting at my dealer waiting for a repalcement mother board. The machine would work fine until it started to heat up (three to five hours), then it would start generating checksum errors up the wazoo. If you turned it off and let it set a few minutes (15-20) it would cool down and work flawlessly for another half hour to hour, then more checksum errors. --George -- George
ifarqhar@sunc.mqcc.mq.oz.au (Ian Farquhar) (01/04/91)
A related issue: why don't the current Amiga filesystem handlers give reasonable facilities to handle bad disk blocks? On large devices, which can have 1% or 2% of their blocks faulty, this becomes a major issue. Having, in my time, probably installed around a hundred hard disks, I would also say that a dynamic monitoring of bad blocks that automatically marked any that failed a write-verify would be useful. -- Ian Farquhar Phone : 61 2 805-9400 Office of Computing Services Fax : 61 2 805-7433 Macquarie University NSW 2109 Also : 61 2 805-7420 Australia EMail : ifarqhar@suna.mqcc.mq.oz.au
thad@cup.portal.com (Thad P Floryan) (01/04/91)
telam@pyrps5.pyramid.com (Thomas Elam) in <139834@pyramid.pyramid.com> writes: > 1. equivalent to UNIX's "fsck" > 2. equivalent to UNIX's "fsdb" > 3. easy and convenient (ideally automatic) bad-block mapping > while online (SCSI *can* do this automatically in case you > were unaware) Thad, how would the file system get involved in the bad-block mapping? The file system only indirectly gets "involved" with bad-block mapping. Consider what happens if a block presently associated with a file gets "mapped out". Bingo, inconsistent file. The SCSI OS can be instructed (using tools such as the ones I mentioned can be found at "adaptex") to automatically map out bad blocks upon writing, and the OS (i.e. filesystem) would never even know about it, since the SCSI OS still presents "sequential"(ly numbered blocks) to the device driver. In my experience, bad blocks are "found" when doing a read after write operation; the SCSI devices can detect this "automagically" if instructed to do so and thus the user won't see any problem. Of course, if later a block is found "bad" during a read, then you better have a recent backup! :-) >[instructions on how to uucp information deleted] For those of us for which ftp is much easier to use than is uucp, how can we get the list and description? For example, could you give us a phone number for voice communication or a postal address? Heh! I've been WAITING for a question like this for some time. Seems people don't know the PURPOSE of the NSF-sponsored Internet (re: ftp). Read on ... [BTW, "NSF" = National Science Foundation] Recently, in comp.protocols.tcp-ip, the Director of BARRnet (Bay Area Regional Research network, affiliated with the NSF's Internet) started blasting people who were using the Internet for "personal" email; BARRnet is based at Stanford. He was responded-to by another person who asked if he (the BARRnet Director) personally examines all email exiting Stanford to be SURE that none of Stanford's professors were using email over BARRnet/Internet for their "outside " consulting work. Silence. Last year, the Houston Chronicle (not sure of the name, but a major newspaper there) published an expose' regarding use of the taxpayer-supported Internet for PORNOGRAPHY, SEX, and other VILE and EVIL things; specifically, the transmission of the daily multi-megabytes of alt.sex.pictures. The shit very quickly hit the fan, and Congress will soon be examining ALL use of the NSF Internet. Just think what will happen to everyone who "ftp's" to get their daily dose of Amiga games and whatnot from abcfd20 ... bingo, possibly Federal Fine$$$ and your picture on the walls of US Post Offices! :-) The charter of the NSF-funded Internet is for research and government-sponsored activities ONLY. I'm really surprised no-one's cracked down before. This year should be interesting ... In any event, the system on which Roy Neese makes his software available is NOT available via ftp since he's a commercial enterprise; his system is reachable using uucp per the info I posted yesterday. You could probably check the uucp maps for his phone number; I don't have them readily available; or you could call Adaptec (Milpitas CA) or the info operator for Houston TX which is where I believe "adaptex" is located. Remember, too, Roy's programs ONLY work on IBM-PCs, and I mentioned them only because we NEED those kind of tools for the Amiga (should someone be ambitious enough to clone them). One more point about "ftp" access: the uunet people have started Alternet which is NOT funded by us taxpayers, and THAT will be available for commercial and non-research use. As for gateways, traffic-monitoring, etc. suggest you follow the message threads in the appropriate newsgroups. Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
peter@sugar.hackercorp.com (Peter da Silva) (01/04/91)
In article <1991Jan3.230319.3648@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > I've heard that C= plans to limit the possibility of corrupting a > file system even more in Ver 2.0. Something about updating the disk so as to > keep little of it's static state in RAM. After C= implements this, the Amiga's > file system will probably fall into this realm you see all other file > systems in. That's not good enough... it's still susceptibale to bad blocks, etc. I used to gripe about the Amiga file system, and everyone kept telling me there must be something wrong with my drives (so I had 'em serviced, no dice), or that it's just trackdisk.device (so? They wrote that too), or whatever. But things would be better on the hard disk. So I shut up and waited. Now I have a hard disk and I've already had to format a partition because something in It's Only Rock and Roll (which is just *data!*) busted it... twice. I've got some 40 UNIX boxes with on the order of 1 Gig of disk on each at work. I've never had to format a partition because of a software problem. The Amiga needs a working FSCK. You can keep less stuff in RAM and reduce the window in which a bug can bite you quite a bit... at the cost of performance. But you can still get bitten. No, the Amiga needs a file system repair utility that can be trusted, and that doesn't force me to keep a spare partition to salvage the disk structure into. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (01/05/91)
In article <7455@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Jan3.230319.3648@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >> I've heard that C= plans to limit the possibility of corrupting a >> file system even more in Ver 2.0. Something about updating the disk so as to >> keep little of it's static state in RAM. After C= implements this, the Amiga's >> file system will probably fall into this realm you see all other file >> systems in. > >That's not good enough... it's still susceptibale to bad blocks, etc. I used >to gripe about the Amiga file system, and everyone kept telling me there must >be something wrong with my drives (so I had 'em serviced, no dice), or that >it's just trackdisk.device (so? They wrote that too), or whatever. But things >would be better on the hard disk. > >So I shut up and waited. > >Now I have a hard disk and I've already had to format a partition because >something in It's Only Rock and Roll (which is just *data!*) busted it... >twice. I've got some 40 UNIX boxes with on the order of 1 Gig of disk on each >at work. I've never had to format a partition because of a software problem. > >The Amiga needs a working FSCK. You can keep less stuff in RAM and reduce >the window in which a bug can bite you quite a bit... at the cost of >performance. But you can still get bitten. No, the Amiga needs a file system >repair utility that can be trusted, and that doesn't force me to keep a >spare partition to salvage the disk structure into. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. Newsgroups: comp.sys.amiga,comp.sys.amiga.tech Subject: Re: HD Errors Summary: Expires: References: <cbUFsB200VIFFNxVlN@andrew.cmu.edu> <37492@cup.portal.com> <1991Jan2.190655.15790@jato.jpl.nasa.gov> <1991Jan3.141624.25450@forwiss.uni-passau.de> <1991Jan3.230319.3648@jato.jpl.nasa.gov> <7455@sugar.hackercorp.com> Sender: Reply-To: jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) Followup-To: Distribution: Organization: Jet Propulsion Laboratory, Pasadena, CA Keywords: In article <7455@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Jan3.230319.3648@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >> I've heard that C= plans to limit the possibility of corrupting a >> file system even more in Ver 2.0. Something about updating the disk so as to >> keep little of it's static state in RAM. After C= implements this, the Amiga's >> file system will probably fall into this realm you see all other file >> systems in. > >That's not good enough... tough s___! These UNIX boxes you cite their manafactures have been around for a lot longer than the Amiga has - so their products are quite mature. Plus, there is quite a cost difference between the SUN Sparc and an Amiga. I don't know how you can realistically compare the two. As the Amiga matures so will its file system. I was curious about what a Sparc Station would cost. The barebones without a hard disk is $4995. Didn't see the prices for systems with disks...I estimate that they start around $7000. I must be fortunate that I have experienced little of the hard disk woes you have. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. Jeff
David.Plummer@f70.n140.z1.FIDONET.ORG (David Plummer) (01/05/91)
Likely all that happened was the checksum for that sector became corrupted. All you would have to do it write that one byte... but how to do it? Diskdoctor might fix it, DiskSalv will recover your data. I have a program that will just patch the checksum (I wrote it but never posted it). If you can find a disk editor, such as DiskEd, you could probably just read and re-write the sector, specifying first to fix the checksum. Not to worry, I doubt your data is damaged (except maybe that one file). Don't re-format except as a very last resort. -- David Plummer - via FidoNet node 1:140/22 UUCP: ...!herald!weyr!70!David.Plummer Domain: David.Plummer@f70.n140.z1.FIDONET.ORG Standard Disclaimers Apply...
thad@cup.portal.com (Thad P Floryan) (01/05/91)
jdickson@jato.jpl.nasa.gov (Jeff Dickson) in <1991Jan4.191249.14442@jato.jpl.nasa.gov> writes: tough s___! These UNIX boxes you cite their manafactures have been around for a lot longer than the Amiga has - so their products are quite mature. Plus, there is quite a cost difference between the SUN Sparc and an Amiga. I don't know how you can realistically compare the two. As the Amiga matures so will its file system. I was curious about what a Sparc Station would cost. The barebones without a hard disk is $4995. Didn't see the prices for systems with disks...I estimate that they start around $7000. What does price have to do with it? Once, in a sadistic mood, I "played" with one of the office IBM-PCs (actually an IBM machine) and rebooted it perhaps 30 times in one hour while writing to its HD. Not any problems at all. Robust file system. Several of my UNIX systems are AT&T's 3B1, a 68010-based demand-paged virtual memory system that is contemporary with the Amiga ... both came out in 1985 and appear so much alike one would think they were two models from the same company (e.g. same color, keyboard garages, 2 or 3 button mouse, choice of windowing menu or command-line interfaces, etc.); point being, I can do "bad" things to the 3B1 and NOT trash the file system. And one person in the Silicon Valley AT&T UNIX Users' Group did do a real nasty: mounted the file system as a partition of itself. He, of course, panicked when things started going ape, so he brought his machine to the Users' Group meeting and Jim Sanchez and I spent a few minutes with fsck and his system was up and running again with NO loss of any important files and no need to reformat and reload (this was one year ago and that system is still running fine). Now, contrast all the above with all the HD laments in this newsgroup, and one would easily draw the conclusion that if you stare cross-eyed at or sneeze in the same room as an Amiga the filesystem will go belly up, requiring reformatting and reloading from a backup. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |||||||||||||||||||||||||||||||||||||||| THIS IS THE ISSUE ABOUT WHICH EVERYONE is rightfully concerned, and was why I made the comment about the fragility of the Amiga's filesystem. As another example, I built a complete HD subsystem for an Amiga owned by a colleage in my office. I tested it for two weeks in my lab and it was rock solid, never a problem. If he uses it for more than 2 minutes, he starts getting HD errors requiring reformatting. I bring it back, works fine for me. He tries it again, it goes belly up. After three iterations, I said "to hell with this" and recommended he get a Mac, which he did, and now he left and formed his own company ("Abra-Mac-Dabra") and is doing a booming business and has no HD errors (he simply was NOT an "Amiga" person :-) He gave the Amiga to his son who IS an "Amiga" person and is able to use the SAME system with no problems whatsoever. You figure! :-) And in my own case, I don't get any HD errors, but then I run "safe" software (as I discussed in comp.sys.amiga.tech) and I run my Amiga systems with proper surge protection and UPS power backups 24 hrs/day, 7 days/week. I do do regular backups because I anticipate the system will fail at some point, but at least it won't be a disaster when it does. And, as a side note, several of my UNIX boxes have never been backed up but I don't anticipate any problems should a HD error occur ... simply because the filesystem isn't as fragile as that on the Amiga. It was the EXTREMELY high rate of HD errors and failures that I've seen with the Amiga (and which you see in this newsgroup and on BBS systems) that influenced my company's decision to not continue developing our products under AmigaDOS. SVR4 on the Amiga is a different beast and one with which I can feel comfortable doing my company's software on an Amiga platform. It's one thing for a system to crash while playing a game, but such a crash while running a $10,000+ software package performing a company's business is simply not acceptable or tolerable. Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]
jesup@cbmvax.commodore.com (Randell Jesup) (01/05/91)
[ first a side note: jdickson, your news software is messed up. It posts the entire initial message, then your new message (sometimes to a different group). It may be the way you edit messages, also. ] In article <1991Jan3.230319.3648@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > I've heard that C= plans to limit the possibility of corrupting a >file system even more in Ver 2.0. Something about updating the disk so as to >keep little of it's static state in RAM. After C= implements this, the Amiga's >file system will probably fall into this realm you see all other file >systems in. This is already in 2.0 - it no longer keeps a memory copy of the entire allocation table, it gets it from disk as needed (or some such). 1.3x FFS is quite reliable - I never had it trash a partition. 2.0 FFS is more reliable yet (and better at defragging), and for those that like data safety more than speed, it support OFS format as well (though obviously slower than FFS format, due to the headers on the data, especially on a DMA HD. On a non-DMA HD, the difference will be less pronounced, but still very noticable.) Another point to realize is that most amiga users wouldn't know what to do with an fsck-equivalent. For non-simple problems, you had better have at least a modicum of knowlege about what a FS is (ditto on Unix - imagine you sterotypical person who uses Unix for word processing trying to deal with a non-simple problem reported by fsck). Unix does have more redundancy in their FS, though that has negative effects on speed, and the inode/data partitioning may help some, though it adds some annoying limits at times. BTW, I test new versions of Dos.library live on my development machine (and the latest version of the FS Steve has released at a given time), and have never trashed a drive or lost data. Had to reboot more than a few times, of course. ;-) A nice side-effect (for others) is that if there's a bug in Dos, I usually find it early on. (I admit I'm less likely to lose data with dos than a test version of the FS, though I often edit and compile new versions of dos under the test version of dos.) -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
jesup@cbmvax.commodore.com (Randell Jesup) (01/05/91)
In article <37568@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >Consider what happens if a block presently associated with a file gets "mapped >out". Bingo, inconsistent file. The SCSI OS can be instructed (using tools >such as the ones I mentioned can be found at "adaptex") to automatically map >out bad blocks upon writing, and the OS (i.e. filesystem) would never even know >about it, since the SCSI OS still presents "sequential"(ly numbered blocks) to >the device driver. Well, some SCSI drives can. Last I checked, it was a vendor-specific command (which quantum has), though it may have found it's way into SCSI-2. > In my experience, bad blocks are "found" when doing a read >after write operation; the SCSI devices can detect this "automagically" if >instructed to do so and thus the user won't see any problem. Of course, if >later a block is found "bad" during a read, then you better have a recent >backup! :-) Once again, I think this is a vendor-specific command. SCSI can also tell you on a read that the data was bad but the ECC recovered it, and quantums will remap the block (without losing data). If you use HDToolBox to Verify a drive ("Verify data on drive", SCSI Verify command), it will notice recovered read errors (and full errors, of course), and let you map them out. The Amiga standard is that bad-block mapping be handled at the device level or lower (which happens to work quite well with how SCSI is set up), and that the FS is presented with an array of fully usable blocks, which of course is why bad-block mapping isn't in the FS (it would be silly to have it there AND in the SCSI device itself). The scsidirect standard makes it easy to write programs to send arbitrary SCSI commands, regardless of the controller you own (if they follow the standard, of course). Therefore, it's easy to write utilities that set up things like the quantum auto-remapping feature (or do just about anything else). I know at least two people have programs to do all sorts of scsidirect tricks, but they don't seem to have released them (or I missed them, quite easy given how busy I am). It _really_ is quite simple to use scsidirect if you know exec I/O and have some sort of drive/scsi manual. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
thad@cup.portal.com (Thad P Floryan) (01/05/91)
A short while ago I posted a response to jdickson@jato.jpl.nasa.gov (Jeff
Dickson) re: Amiga filesystem fragility, and commented:
What does price have to do with it? Once, in a sadistic mood, I
"played" with one of the office IBM-PCs (actually an IBM machine) and
rebooted it perhaps 30 times in one hour while writing to its HD. Not
any problems at all. Robust file system.
That was Microsoft's MS-DOS 3.10, circa 1984, 7 years ago. I tormented that
system during an office party (yeah, we were all drinking and going crazy! :-)
but couldn't get it to fail. Secretary even sat on the keyboard (and she's a
B-I-G gal! :-) and that system is still working today in one of our branch
offices. THAT's the kind of "robustness" one needs in a business environment.
But the real reason for this followup posting is to iterate why I feel the
problem(s) with the Amiga's filesystem NEED TO BE FIXED: to improve the
"image" of the Amiga, to enhance its credibility, and to prevent any more
lost opportunities.
Lost opportunities?
Yes. Big Bucks. Mucho shekels. Lotsa bread. I posted earlier the anecdote
concerning the person for whom I built a HD subsystem for his Amiga ...
As another example, I built a complete HD subsystem for an Amiga owned
by a colleage in my office. I tested it for two weeks in my lab and
it was rock solid, never a problem. If he uses it for more than 2
minutes, he starts getting HD errors requiring reformatting. I bring
it back, works fine for me. He tries it again, it goes belly up.
After three iterations, I said "to hell with this" and recommended he
get a Mac, which he did, and now he left and formed his own company
("Abra-Mac-Dabra") and is doing a booming business and has no HD
errors (he simply was NOT an "Amiga" person :-) He gave the Amiga to
his son who IS an "Amiga" person and is able to use the SAME system
with no problems whatsoever. You figure! :-)
I want to elaborate on this as a case history; you may find this interesting.
I've mentioned previously that I "do" 4GL products, DBMS products, etc. as
part of one company's primary business.
Four years ago, a salesman in my company wrote on his own time an application
(in my product) as a "Human Resources Management" system (to do all the stuff
required under US Federal law for company reporting (to the US Gov't)). It
worked so well, he re-wrote it in dBASE on an IBM-PC and left to form his own
company, Abra-Ca-Dabra, which is now doing over $10,000,000/year in sales,
moved to Florida, and has a staff of over 20 people. The product's name is
also "Abra-Ca-Dabra."
Two years ago, another salesman in my company wanted to put that product on
the Amiga using some dBASE-like clone, and licensed the code from the original
person. That's the Amiga system for which I built the HD subsystem. What
with the crap dBASE-like clones and the continuous HD errors on his Amiga (only
when HE used it! :-), he took my advice, bought a Mac, renamed HIS company to
be "Abra-Mac-Dabra" (from "Ami-Ca-Dabra" or whatever :-) and is now succesful
selling that Mac-port.
Point being: that COULD have been an Amiga product with big-$$$ revenues and a
win-win situation for everyone (CBM, the salesman, the Amiga community (due to
more Amigas being sold), etc.).
When we're talking "business software", we're NOT talking small-potatoes. We
sold over 2,000 copies of one of my company's products to the IRS for use on
UNIX and with their PC-laptops. Other clients include the world's largest
banks (one of which does their daily world-wide traveller's check processing
using my product), all branches of the US Armed Forces, foreign governments
(why do you think I test modems calling Canada, Chile, England, France,
etc.?), etc.
I look at some of the above and consider them as lost opportunities for the
Amiga due to its one perceived major glaring problem. Believe me, I tried,
and convinced the company's Board of Directors to give Ami a try, but we kept
getting sabotaged by several 3rd party Amiga-vendors and by intrinsic problems
such as the rash of HD problems. So now we're going to UNIX since the "window
of opportunity" there is still open and because UNIX has become a de facto
"standard" due to Federal procurement mandates. And I look forward to SVR4
on the Amiga as a "second chance" for our products on an Amiga platform.
And as I commented previously here and in comp.unix.aux, it's my belief that
A/UX is an Apple marketing-ploy to get Macs into the federal sector (re: the
federal "UNIX" mandate for multi-tasking), confirmed by public and email
statements from members of Apple's A/UX development team who asked me:
"If you didn't want the MacOS, why'd you get A/UX?"
In every respect except filesystem integrity, the Amiga is by far a better
system than the IBM-PCs and Macs, but clients' perception of the Amiga as a
"toy" due to its problem(s) prevents my company making an inroad with the Amiga
and I'm sure is hurting other people's efforts too.
[This commentary should also more completely answer those who've called asking
why I didn't renew my company's "commercial developer" status for the Amiga;
for what it's worth, I did renew the Apple Developer because they do have a
form of UNIX and it more-or-less works though it's horribly obsolete.]
I hope some of this stimulates further discussion. Let the fires F-L-A-M-E !
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]peter@sugar.hackercorp.com (Peter da Silva) (01/05/91)
In article <1991Jan4.191249.14442@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > tough s___! These UNIX boxes you cite their manafactures have been > around for a lot longer than the Amiga has - so their products are quite > mature. Plus, there is quite a cost difference between the SUN Sparc and an > Amiga. I don't know how you can realistically compare the two. Well, the UNIX box in my bedroom cost me about half what my Amiga 3000 did, so I can't imagine how I could realistically compare the two. The Amiga is a *much* more powerful machine with a better hardware design. But if you want to compare a *less* mature file system, then MS-DOS handles disk corruption a whole lot better than AmigaOS does. Always has. The basic problem seems (to me, at least) to be gratuitous complexity in the file system. Both DOS and UNIX use much simpler file systems that have built-in high level redundancy. AmigaOS has a modicum of low-level redundancy, less with the FFS, and a *very* complex directory scheme that really doesn't add much capability over a straight V7 UNIX file system. Oh, a word to the wise... how about editing your followups a bit better? You managed to include two copies of my message, headers and all. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (01/05/91)
In article <17128@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > Another point to realize is that most amiga users wouldn't know what > to do with an fsck-equivalent. So why do you provide one (DiskDoctor)? One that doesn't work very well, at that. About the only time we have to do more than "fsck -y" is when there are physical disk problems. I'll agree with you that for non-simple problems, you need more smarts. But how about at least providing a reliable DiskDoctor for the 90% case, and an in-place fsck for developers? DiskSalv isn't really a viable alternative for hard disks. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
chanson@isis.cs.du.edu (Chris Hanson) (01/06/91)
In article <17128@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > > Another point to realize is that most amiga users wouldn't know what >to do with an fsck-equivalent. For non-simple problems, you had better have >at least a modicum of knowlege about what a FS is (ditto on Unix - imagine >you sterotypical person who uses Unix for word processing trying to deal with >a non-simple problem reported by fsck). Unix does have more redundancy in >their FS, though that has negative effects on speed, and the inode/data >partitioning may help some, though it adds some annoying limits at times. Good point, there. And you see this echoed back onto AmigaDOS: If you have a good tool (fsck on Unix, DiskX or Sectorama under AmigaDOS), you can certainly make a go at psychoanalyzing your drive. My Palomax HD occasionally gets itself slightly spammed during developement, and I have only had to reformat it once. If you can determine for yourself what the problem actually is, it is often no trouble at all to go and twiddle with DiskX and cure your partition's mental problems. ;) Even the old 1.3 weirdness of let's-move-a-directory-into-one-of-its- children could be solved with a quick boot of DiskX. Though I thank thee ye merry folks at Commodore-Amiga for fixing that in 2.0. Less things to worry about. Now if ye'd just toss those nasty hash tables... <grin> >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup >The compiler runs >Like a swift-flowing river >I wait in silence. (From "The Zen of Programming") ;-) Beautiful quote. Consider my one hand clapping. Chris - Xenon -- #define chanson Christopher_Eric_Hanson || Lord_Xenon || Kelson_Haldane I work, but you don't know who I work for. And they don't know I'm here. "We apologize for the inconveniences." -GOD. (According to D. Adams)
ranma@noc.arc.nasa.gov (Robert Michael Gutierrez) (01/06/91)
jesup@cbmvax.commodore.com (Randell Jesup) writes: > Another point to realize is that most amiga users wouldn't know what > to do with an fsck-equivalent. For non-simple problems, you had better have > at least a modicum of knowlege about what a FS is (ditto on Unix - imagine > you sterotypical person who uses Unix for word processing trying to deal with > a non-simple problem reported by fsck). Well, then write a good interface to an Amy version of fsck. Odd that in the Messy-DOS world, there's a TON of software to help fix trashed FS's (like Norton, PC Tools, etc), and hundreds of thousands of these are sold to the public at large. I would imagine that most of these purchasers are not hardware or developer types, and rely on using the menus to guide and warn them on what happens. Wasn't the Amy OS built on 'user interface'??? I can NOT use my Syquest on FFS without seeing eventual errors crop up. ALL my Syquest carts are OFS formatted. With 40 megs worth of anim files to deal with, I can't afford to do it any other way! And these wern't simple valadation errors...these were bad read/write errors that always got me stuck on a bad block. I personally don't like to spend 2-3 hours with disksalv recovering that cartridge. Believe me, if I could do my animations/playbacks/overlays/subtitling on an IBM PC, my Amy would have been history looong ago. robert gutierrez NASA science internet, network operations center.
skank@iastate.edu (Skank George L) (01/06/91)
In article <1991Jan5.235810.25940@nas.nasa.gov> ranma@noc.arc.nasa.gov (Robert Michael Gutierrez) writes: >jesup@cbmvax.commodore.com (Randell Jesup) writes: >> Another point to realize is that most amiga users wouldn't know what >> to do with an fsck-equivalent. For non-simple problems, you had better have >> at least a modicum of knowlege about what a FS is (ditto on Unix - imagine >> you sterotypical person who uses Unix for word processing trying to deal >> with a non-simple problem reported by fsck). > >Well, then write a good interface to an Amy version of fsck. Odd that in the >Messy-DOS world, there's a TON of software to help fix trashed FS's (like >Norton, PC Tools, etc), and hundreds of thousands of these are sold to >the public at large. Hmmm... I wonder why that is??? :) Our ITT (IBM-XT clone) has had a ton of hard drive errors, all related to bad blocks. It takes hours to check the disk for bad blocks using Norton Utilities. I can check the entire file system on my A3000 for bad blocks in about five minutes. I've had programs crash while writing files, *and* had something on my mother board go bonkers while writing files, and never had something I couldn't fix just by deleting the file. I'm using 2.0. -- Fast cars, + --George Fast women, + Fast computers. (Not necessarily in that order)
blgardne@javelin.es.com (Blaine Gardner) (01/07/91)
jesup@cbmvax.commodore.com (Randell Jesup) writes: > I know at least two people have programs to do all sorts of scsidirect >tricks, but they don't seem to have released them (or I missed them, quite >easy given how busy I am). If there are any scsi.direct utilities that have been released, I'd be very interested in more info on them, and where to find them. -- Blaine Gardner @ Evans & Sutherland 580 Arapeen Drive, SLC, Utah 84108 blgardne%javelin@dsd.es.com ...dsd.es.com!javelin!blgardne (I hope) {decwrl, utah-cs}!esunix!blgardne DoD #0046 My other motorcycle is a Quadracer. BIX: blaine_g
jesup@cbmvax.commodore.com (Randell Jesup) (01/07/91)
In article <1991Jan5.235810.25940@nas.nasa.gov> ranma@noc.arc.nasa.gov (Robert Michael Gutierrez) writes: >Well, then write a good interface to an Amy version of fsck. Odd that in the >Messy-DOS world, there's a TON of software to help fix trashed FS's (like >Norton, PC Tools, etc), and hundreds of thousands of these are sold to >the public at large. I would imagine that most of these purchasers are >not hardware or developer types, and rely on using the menus to guide and >warn them on what happens. Wasn't the Amy OS built on 'user interface'??? Amusing comment, given other people's contentions that MSDOG filesystems are rock-solid. >I can NOT use my Syquest on FFS without seeing eventual errors crop up. ALL >my Syquest carts are OFS formatted. With 40 megs worth of anim files to >deal with, I can't afford to do it any other way! And these wern't simple >valadation errors...these were bad read/write errors that always got me stuck >on a bad block. These sound like real hardware errors, not FS screwups. If the bad block is in a file, you could delete the file (if the drive is still writable or you're good with a sector editor), but if you continue to use it you'll hit the bad block again soon. You need to reformat, or map out the bad block. If the error is in a fileheader or directory block, you may be screwed and have to use disksalv/doctor to get some data back. I would think syquests should be more reliable than that. What's the MTBF? Are these old drives/carts? Have you talked to Syquest? The only way to get R/W errors is a media/hardware problem, or turning off the power (or resetting) in the middle of a write. Is there much dust or smoke (or any other contaminant) where they're kept? If you have a 2091 (and perhaps other controllers), use "Verify Data on Drive" every so often. This causes the drive to make sure all the sectors are ok, and report any bad ones, including recovered errors, so you can map them out before the go bad (hopefully). Could you spell out your hardware config, including rev number of the Syquest roms if you know it, or when it was obtained? -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
thad@cup.portal.com (Thad P Floryan) (01/07/91)
jesup@cbmvax.commodore.com (Randell Jesup) in <17158@cbmvax.commodore.com>
writes:
[...]
Amusing comment, given other people's contentions that MSDOG
filesystems are rock-solid.
[...]
I hope you weren't referring to MY anecdote describing my tormenting the
IBM-PC and not being able to get it to fail! :-) :-)
I never, EVER thought I'd have something "good" to say about MS-DOS and an
IBM-PC, esp. when my favorite "line" at user group meetings is:
"MS-DOS vadanya"
Given the acknowledged presence of the Norton and other tools, there ARE
obviously some failure modes. But I couldn't induce them during that "party."
But I *can* demonstrate (with 10 seconds to set it up) total corruption of the
filesystem on a Amiga simply by writing a file and turning on/off a modem on
the same circuit (but not in my office, home or lab since I do have surge and
transient protection on the AC circuits). Perhaps something similar to that
is what also trashes the MS-DOS filesystem; I cannot try that now since that
machine is 450 miles away in our Orange County office.
Hmmm, wonder if the REAL problem is not software but, instead, hardware re:
AC power line trash. My own Amigas are rock-solid, but ALL of them are run
on protected AC circuits along with UPS systems.
Double hmmm, but that wouldn't explain the situation about the Abra-Mac-Dabra
guy who only needs to look at his Amiga and he'll be greeted with a corrupted
filesystem but his son, using it in the same place, same AC power line, has no
problems at all.
Maybe bad karma! :-)
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]peterk@cbmger.UUCP (Peter Kittel GERMANY) (01/07/91)
In article <17128@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > BTW, I test new versions of Dos.library live on my development >machine (and the latest version of the FS Steve has released at a given >time), and have never trashed a drive or lost data. Well, the question always remains, who trashes the disk, a program or the DOS? I have a proposal for real hard tests: Go BASIC, take the SaveILBM program made by Carolyn and compile it with AC/Basic. This crashes your machine perfectly and with a good chance you are left with a corrupted disk (hit two of mine on one single day, but I succeeded to fix them with some self-made special proggies). I'm sure this is due to the compiler, but again, this calls DOS routines to get onto the disk. But perhaps it corrupts the stack, so that these calls run wild (pure guess). -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
jap@convex.cl.msu.edu (Joe Porkka) (01/08/91)
thad@cup.portal.com (Thad P Floryan) writes: >jesup@cbmvax.commodore.com (Randell Jesup) in <17158@cbmvax.commodore.com> >writes: How about a little test folks, instead of a bunch of rambling on and on.... Get a copy of the MessyFileSystem. Get a spare partition on a harddisk, put MessyFileSYstem on that paratition, and try it out! I may try it, but Iv'e only got 20megs to begin with. Great thing about the amiga, if you dont like the systems filesystem, then simply use another!
david@dogmelb.dog.oz.au (David Le Blanc) (01/08/91)
In article <17158@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes: > In article <1991Jan5.235810.25940@nas.nasa.gov> ranma@noc.arc.nasa.gov (Robert Michael Gutierrez) writes: > > >I can NOT use my Syquest on FFS without seeing eventual errors crop up. ALL > >my Syquest carts are OFS formatted. With 40 megs worth of anim files to > >deal with, I can't afford to do it any other way! And these wern't simple > >valadation errors...these were bad read/write errors that always got me stuck > >on a bad block. Hey! Aren't SyQuest drives a removable media drive?!?!?!!? Since when did FFS support removable media?!!? The only places I have seen a SyQuest work properly are with a GVP controller using a *** Specially hacked FFS *** to deal with removable media, and under 2.0. If that is the case, then when ever you switch disks, the FFS doesnt know about it, and the next time you write to the disk, you probably write the wrong bitmap back!!! It may take several disk swaps, and maybe several boots/days to fully kill a disk, but I can see it happening... PS, I borrowed a SyQuest from a friend, and proved to myself the commodore controller couldnt handle the removable media. And YES, I got read write errors galore! WB2.0 fixed this! > Randell Jesup, Keeper of AmigaDos, Commodore Engineering. > {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup -- Email: david@dogmelb.dog@munnari.oz | Division of Geomechanics, TEL. (03) 881 1355 | CSIRO, P.O. Box 54 FAX (03) 881 2052 | Mt Waverley 3149, | AUSTRALIA.
telam@pyrps5.pyramid.com (Thomas Elam) (01/08/91)
In article <17158@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <1991Jan5.235810.25940@nas.nasa.gov> ranma@noc.arc.nasa.gov (Robert Michael Gutierrez) writes: >>Well, then write a good interface to an Amy version of fsck. Odd that in the >>Messy-DOS world, there's a TON of software to help fix trashed FS's (like >>Norton, PC Tools, etc), and hundreds of thousands of these are sold to >>the public at large. I would imagine that most of these purchasers are >>not hardware or developer types, and rely on using the menus to guide and >>warn them on what happens. Wasn't the Amy OS built on 'user interface'??? > > Amusing comment, given other people's contentions that MSDOG >filesystems are rock-solid. > >>I can NOT use my Syquest on FFS without seeing eventual errors crop up. ALL >>my Syquest carts are OFS formatted. With 40 megs worth of anim files to >>deal with, I can't afford to do it any other way! And these wern't simple >>valadation errors...these were bad read/write errors that always got me stuck >>on a bad block. > > These sound like real hardware errors, not FS screwups. If the bad >block is in a file, you could delete the file (if the drive is still writable >or you're good with a sector editor), but if you continue to use it you'll hit >the bad block again soon. You need to reformat, or map out the bad block. >If the error is in a fileheader or directory block, you may be screwed and >have to use disksalv/doctor to get some data back. > > I would think syquests should be more reliable than that. What's the >MTBF? Are these old drives/carts? Have you talked to Syquest? The only >way to get R/W errors is a media/hardware problem, or turning off the power >(or resetting) in the middle of a write. Is there much dust or smoke (or >any other contaminant) where they're kept? > > If you have a 2091 (and perhaps other controllers), use "Verify Data >on Drive" every so often. This causes the drive to make sure all the sectors >are ok, and report any bad ones, including recovered errors, so you can map >them out before the go bad (hopefully). Could you spell out your hardware >config, including rev number of the Syquest roms if you know it, or when it >was obtained? Randell: A dealer told me Commodore would not support the Syquest with the 2091. Is that hogwash? (Hope you answer soon: the dealer has a TrumpCard on order, even though I resisted get a second controller; I have a 2091.) >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup >The compiler runs >Like a swift-flowing river >I wait in silence. (From "The Zen of Programming") ;-) Tom
mikep@hpmwtd.HP.COM (Mike Powell) (01/09/91)
Can an SyQuest equipped Amiga work correctly as long as 'diskchange' is used every time? Or is there something else going on here.... -Mike-
new@ee.udel.edu (Darren New) (01/10/91)
In article <730033@hpmwngf.HP.COM> mikep@hpmwtd.HP.COM (Mike Powell) writes: > Can an SyQuest equipped Amiga work correctly as long as > 'diskchange' is used every time? Or is there something else > going on here.... Works fine for me. I have an A1000, CLtd controller, StarBoard. -- 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 ... +=+=+=
ranma@noc.arc.nasa.gov (Robert Michael Gutierrez) (01/10/91)
jesup@cbmvax.commodore.com (Randell Jesup) writes: > ranma@noc.arc.nasa.gov (Robert Michael Gutierrez) writes: > >Well, then write a good interface to an Amy version of fsck. Odd that in the > >Messy-DOS world, there's a TON of software to help fix trashed FS's (like > >Norton, PC Tools, etc), .... > Amusing comment, given other people's contentions that MSDOG > filesystems are rock-solid. You do have a good point. We probably should change our tune to Messy-DOS files systems are easily recoverable, as opposed to good file systems. Are there such things as 'good file systems'??? > >I can NOT use my Syquest on FFS without seeing eventual errors crop up.... > These sound like real hardware errors, not FS screwups. If the bad > block is in a file, you could delete the file (if the drive is still writable > or you're good with a sector editor), but if you continue to use it you'll hit > the bad block again soon. You need to reformat, or map out the bad block. > If the error is in a fileheader or directory block, you may be screwed and > have to use disksalv/doctor to get some data back. Aha! This is the fun part. The Syquest's were originally on 2090a's, in an external box (yes, I've got the terminators right!). On the 2090a, I could FFS format, but eventually, I would get the famous 'read/write' error. OK, disksalv the contents, then reformat. The format does NOT report any bad blocks. Stuff the old contents back into the Syquest. Give it about a month, WHAM! Another 'read/write' error. Eventually OFS formatted the disk, no problems in 3 months use. Now, got the 2091. HDTools says 1 head, 2550 sectors (approx). Used one partition (I need the space!!!), FFS. Format and data verify, all clean. Start moving files onto the cart, WHAM! 'read/write error'. OK, HDTools Data Verify says no errors! Format again, turn off reselection this time, and WHAM! 'read/write error'. > I would think syquests should be more reliable than that. So would I... > What's the MTBF? Specs never published... > Are these old drives/carts? All brand new. 6 of them. 2 previously used on my Messy-DOS system *in the same drives and box* on an NCR SCSI controller, no problems. Used the same Centronics to DB-25 cable on the box. > Have you talked to Syquest? Will tomorrow at MacWorld, hopefully. Otherwise, they are approximately 20 blocks away from my house, In Fremont, Calif. > The only > way to get R/W errors is a media/hardware problem, or turning off the power > (or resetting) in the middle of a write. Is there much dust or smoke (or > any other contaminant) where they're kept? Nope. Never powered down during anything. No way to 'reset' without a scsidirect command. No external 'reset' button. No 3-finger-salute during read/writes, except today, I had HDTools disappear during another lockup. This latest lockup occured when I was trying to poll the Syquests, and the system froze as it was reading the info from the Syquests. AFter the reboot, I got a Key Validation message. Disksalved everything, but my HDTools is now corrupted. Oh, I got my Amy used, so I don't have the diskette for HDTools. Does anybody have a copy of HDTools for the 2091??? Considering that it only works with the 2091 (maybe others?), I doubt I would have any piracy intentions in mind :-) > Could you spell out your hardware > config, including rev number of the Syquest roms if you know it, or when it > was obtained? Rev 6.2 mother, unknown rev 2091 ["(c) 1990" ROMS] w/2 megs, Syquest F3H ROMS (may have to check that to make sure), 8-up memory board w/6 megs. I just got 'Quarterback Tools' today, and will try to give the Syquest's a hit with it and see what it says. robert
jal@pandora.cs.wayne.edu (Jason Leigh) (01/10/91)
My company recently purchased SyQuest removable drives to connect up to an Amiga 2500 and my 2000 at home. From home I am running GVP's controller and at work I am using Amiga's. I noticed for one thing that the Amiga's controller requires that the first partition be a non-ffs format for it to work. So the disks I format on my 2000 won't work on the 2500. And lately I've been getting the aforementioned corruptions and I have only been performing disk changes on power down. Is there a way to 1. make the disks more compatible? 2. Prevent this corruption? Jason Leigh jal@cs.wayne.edu -- :^) :^) :^) :^) :^) :^) :^) :^) ;^) O^: (^: (^: (^: (^: (^: (^: (^: :^) Where the telescope ends, the microscope begins. (^: :v) Which of the two has the grander view? - Victor Hugo (v: :v) :v) :v) :v) :v) :v) :v) :v) :v( $v: (v: (v: (v: (v: (v: (v: (v:
jesup@cbmvax.commodore.com (Randell Jesup) (01/12/91)
In article <1991Jan10.045625.20489@nas.nasa.gov> ranma@noc.arc.nasa.gov (Robert Michael Gutierrez) writes: >The Syquest's were originally on 2090a's, in an external box (yes, I've got the >terminators right!). On the 2090a, I could FFS format, but eventually, I >would get the famous 'read/write' error. OK, disksalv the contents, then >reformat. The format does NOT report any bad blocks. Stuff the old contents >back into the Syquest. Give it about a month, WHAM! Another 'read/write' >error. Eventually OFS formatted the disk, no problems in 3 months use. > >Now, got the 2091. HDTools says 1 head, 2550 sectors (approx). Used one >partition (I need the space!!!), FFS. Format and data verify, all clean. >Start moving files onto the cart, WHAM! 'read/write error'. OK, HDTools >Data Verify says no errors! Format again, turn off reselection this time, >and WHAM! 'read/write error'. First, I really think you may have a hardware error here. I advise taking it in to Syquest for a check-over. Second, you may have run into a syquest rom revision problem, where it ignores attempts to turn off reselection: if problems persist after getting the hardware checked out, get the latest rom revision from syquest. In particular, have them check the heads and your carts. >> Have you talked to Syquest? > >Will tomorrow at MacWorld, hopefully. Otherwise, they are approximately >20 blocks away from my house, In Fremont, Calif. Good. Let us know the result (for the other syquest owners out there). >Oh, I got my Amy used, so I don't have the diskette for HDTools. Does anybody >have a copy of HDTools for the 2091??? Considering that it only works >with the 2091 (maybe others?), I doubt I would have any piracy intentions >in mind :-) I assume you mean HDToolBox (there is no thing named HDTools). It works interchangably with the A590/A2091/A3000. BTW, due to an unexpected change in the WD part, you may need to turn off reselection to handle multiple drives (as has been discussed here before). I believe the ROMS that fix this are version 6.6. The normal symptom is a scsi-bus lockup (solid light) during copies between drives. When turning off reselection, you need to select your modified drive type without reselection, rebuild all your partitions (write down where they were first!), and then save changes to the drive. You have to be careful, but you shouldn't need to backup/restore (but do a backup first to avoid murphy...) Note that not all controllers have this problem, it depends on chip revision. People with one drive have no problems; it only affects multiple drive setups (and then only under heavy multi-drive load). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)