[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::amiga_v1

Title:AMIGA NOTES
Notice:Join us in the *NEW* conference - HYDRA::AMIGA_V2
Moderator:HYDRA::MOORE
Created:Sat Apr 26 1986
Last Modified:Wed Feb 05 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:5378
Total number of notes:38326

377.0. "Gamma1 WorkBench peculiarities" by BACH::TENNY (Dave Tenny) Sat Mar 14 1987 14:01

I've been using the CA released Gamma1 OS, with WorkBench
33.44.  I haven't used the final release of 1.2.

I've noticed that in Gamma1, after issueing LOADWB,
the disk verification or whatever it is that workbench is
doing takes a very long time.

This appears as just random disk reads for about 30 seconds.

Does the final release of 1.2 do this?  1.1 and the Beta 1.2's didn't.

I have copied all the files to a fresh disk to gain sector allocation
improvements, with no noticeable effect.

Any Ideas?

	Dave
T.RTitleUserPersonal
Name
DateLines
377.1Looking up disk.infoTLE::RMEYERSRandy MeyersMon Mar 16 1987 04:1513
Re: .0

The disk validation process is part of Amiga DOS and runs even if you
never do a LoadWB.

However, when the workbench starts, it opens every disk to see if there
is a custom disk icon (file disk.info) for that disk.  That could account
for the random disk reads when workbench starts.  If you open lots of
files or do lots of logical name assigns, the workbench will even prompt
you to insert disks in drives so it can try and read the icon information
for the disk.

Thirty seconds seems a bit long for this process to continue.
377.2But is it just a flake in gamma1?BIZET::TENNYDave TennyMon Mar 16 1987 12:247
The procedure I used for startup is the same as
what I used for other releases of 1.2, it's only Gamma1
that does this. That's why I wondered if anybody knew
(heard) if gamma1 was peculiar in this respect.
(If so, I have motivation to get the official 1.2 release.)

Dave
377.3Maybe this is it?VIKING::BANKSIn Search of MediocrityMon Mar 16 1987 14:4240
    I once got a lousy copy of a 1.2 field test release, and experienced
    pretty much the same problem.  While I never found what theproblem
    was precisely, I figured out the following scenario which at least
    seems consistent with what's happening.
    
    When you put a disk in a drive, it runs the disk validator to make
    sure it's sane.  Actually, I discovered that there's really two
    pieces of the validator, which for the purposes of this discussion,
    we'll call "little validator" and "big validator".
    
    When you put a disk in a drive, it runs little validator to do the
    sanity check.  If everything looks ok (which it usually does), it
    finishes in a couple of seconds and goes away.
    
    If everything isn't ok, it'll run the big validator.  This isn't
    usually resident, and will have to be loaded from your "system"
    disk.  (Some people have noticed that on a single drive system,
    the mere insertion of a hosed disk into an idle system will nearly
    immediately cause a requester for the system volume.  This is why).
    
    Big validator will run anywhere from a few seconds to almost a minute
    depending on how much stuff there is on the volume.  Its main aim
    in life is to locate the error and to repair it.  Once it's done
    so, it goes away FDH (fat dumb and happy).
    
    The problem that I was experiencing with this bad beta release was
    that there was a file system corruption on the workbench disk, which
    got faithfully reproduced when I DISKCOPYed it to my working copy
    (since it was a "soft" error rather than a broken sector).  Thus,
    when I boot the disk, I get big validator shortly after the system
    boots.
    
    The only question is, why did it happen every time I booted the
    system?  Well, because I had the disk write locked.  Every time
    I'd boot, it'd run big validator, who would eventually find the
    problem, then fail to fix it because the disk was write locked.
    
    The solution was simply to insert the disk once while write enabled.
    After that, no more problems, and it took considerably less time
    to boot the system.