Path: utzoo!mnetor!uunet!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: Semicoherent flame about Amigados.
Message-ID: <3311@cbmvax.UUCP>
Date: 11 Feb 88 23:58:30 GMT
References: <644@nuchat.UUCP>
Organization: Commodore Technology, West Chester, PA
Lines: 67

> Time for my periodic semicoherent flame about Amigados.

You're actually flaming the trackdisk.device...

> It's STILL the least reliable file system... Amigados is just plain flakey...

No, I know some folks can't resist the urge to flame the DOS.  Hey, all that
BCPL code must be doing something wrong, eh?  

And the main problem isn't that full tracks are read and written in one pass.
The problem is that, each time that full track is written, it could start
anywhere.  So, given enough writes, if you have a place that'll drop a bit
on that track, it'll eventually wind up having your important data written
on top of it.  

The ideal solution would be to have trackdisk start it's writes at the same 
place every time.  Then you should be able to add bad block mapping -- even
though the blocks aren't distinct, as long as they get written in the same
place every time, and you avoid placing meaningful data in a known bad
place, your reliability will go up quite a bit.

> Almost every disk error means you lose an entire track, thanks to the 1
> sector per track concept (let's not argue about what a sector is, hey? As
> far as the electronics is concerned it's all one big sector). A good 
> proportion of the time the lost track is the root track, unsurprisingly
> enough.

The root track contains the bitmap, which gets rewritten all the time, so you
would expect that to be the first to go.  Fortunately, the way DOS formats
the disk, you can loose ROOT and BITMAP and still recover everything.  Of
course, you'd rather not have to recover it, eh?

And though you're correct about DOS and DiskSalv and DiskDoctor giving up
on a whole track when it goes, I don't think that for either a write or a
read this should be necessary.  The worst case loss would be when you die
in the middle of a write; you could end up with 2 copies of about 1/2 the
blocks in that track.  If you just lay out one block on a glitchy section
of a track, I think you should be able to get most everything back.  It
would certainly require very low level programming at this point, maybe all
the way down at the disk.resource.

> Please, after you finish the fast file system... get a reliable on. It doesn't
> have to be big: 720K per diskette would be fine. But it needs to have real
> sectors to act as firewalls when corruption occurs (as it invariably does).

Amigas can read and write PC-DOS compatible files on PC formatted disks.  That
says to me that block syncing is also possible.  It's impossible for the 
hardware to write less than a track, far as I know, so true sectors are out.
But a synced track read/write should be just as secure at 11 logical sectors
as it would be with 9.

> Finally, I have a suggestion for the multitasking shuffle. Have LoadSeg keep
> a semaphore for each floppy, and single-thread itself. Make Copy respect it.
> And publish how to use it so that we can make our utilities do the same
> thing.

Now there's a DOS issue, and I fully agree that the disk thrashing you get
into is a needed fix.  If we get a handler in the future that asks for more
than single blocks at a time, this should smoothen things out a bit.

> -- a clone of Peter (have you hugged your wolf today) da Silva  `-_-'
> -- normally  ...!hoptoad!academ!uhnix1!sugar!peter                U
> -- Disclaimer: These aren't mere opinions... these are *values*.
-- 
Dave Haynie  "The B2000 Guy"     Commodore-Amiga  "The Crew That Never Rests"
   {ihnp4|uunet|rutgers}!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
		"I can't relax, 'cause I'm a Boinger!"