Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!pasteur!ucbvax!hplabs!hp-pcd!hpcvca!charles
From: charles@hpcvca.HP.COM (Charles Brown)
Newsgroups: comp.sys.amiga
Subject: Re: Request to Commodore (Bad Blocks)
Message-ID: <5660015@hpcvca.HP.COM>
Date: 12 Sep 88 17:16:46 GMT
References: <8891@cup.portal.com>
Organization: Hewlett-Packard Co., Corvallis, Oregon
Lines: 95

>> Trackdisk.device rejects complete tracks if only one sector is bad.
>> (I verified this with a RAW_READ call and then decoding MFM data). Could
>> anyone think to implement this in 1.4 ?
> Bad idea.

For READING this is not a bad idea.  You should be able to easily
recover as much data from the disk as is good.  Only the impacted
sector(s) is defective.  These are easily distinguished by bad CRC.
It is only writing to a known bad track that is a bad idea.

> Since disk writes aren't locked to the index hole under either
> file system (thank god), any defect on the track will and should take out
> the whole track.  (After all, how do you know where the defect is going to
> land.)

This is a fallacy.  It is only because the index hole is not locked to
the start of the track that you don't know where the defect is going
to land.

The index hole was uncoupled from the track to speed access.  But how
much speed up did it accomplish?  There are three cases:  format,
write and read.

Format:
	Since formatting is done rarely (campared to reads and
	writes), a difference in speed has little effect upon total
	system speed.  I choose to ignore it.
Read:
	Reading does not depend upon the index hole anyway.  It really
	only depends upon where the track was started when it was
	written.
	If you always start a track read at the beginning of a track
	(as written) you will on the average have a 1/2 rotation
	latency waiting for the disk to turn to the start of that
	track.  So decoupling the index hole from the the start of
	track did not speed up reads AT ALL.
Write:
	Writing a track can start at any time.  This will save the
	time of (on the average) 1/2 rotation per track read.  The
	minimum track read takes 1 rotation.  Thus decoupling the
	index hole from start of track speed writes on the average by:
		difference=1/1.5=0.67 or 33%

Now consider typical use.  I don't have real figures so I will try to
make them up.  I would guess that I do reads at least 5 times as much
as I do  writes.  I boot my A1000, use it a couple of hours, and turn
it off.  Booting takes a long time.  Typical editing requires that I
read the editor, read the file to be written, write the file one or
more times.  Typically the editor is a much bigger file that the file
I am editing.  Compiling requires reading several programs (make, cc,
linker) the source(s), several libraries; and one or two files are
written.  So now how much speed did I gain?

The following numbers represent time in terms of track rotations:
		  write	+ read (weighed)
 index coupled:   1.5	+ 5*1.5		= 9.0
 index decoupled: 1	+ 5*1.5		= 8.5
Now the advantage of decoupled index drops to 8.5/9.0=0.94 or 6%

So we gave up track reliability for at best a 6% increase in overall
floppy speed.  That strikes me as a bad trade.

> For floppies the point is moot.  Use disks without flaws.  They
> aren't very difficult to find, and flawed disks will always end up being
> more trouble than they're worth.

How do you know a disk has no flaws?  Formatting it does not tell you.
The format program only puts data on parts of the track.  Other parts
of the track can be flawed and will still pass Format/Verify.  There
are two types of areas unchecked by Format.  The gaps between sectors
are not given data.  The space between the end of the track and its
own beginning has no data.  When the index hole is coupled to the
track start, these gaps are fixed in location and will never cause a
problem.  When the index hole is decoupled, they move about.  Then you
really have no way of knowing that the disk you are using is flawless
until it fails.

> If presented with a bad block the filesystem 
> assumes the worst, and ignores the track completely.  Wonderful, nicht?
>                            -Sullivan Segall

Nicht!

This flaw (decoupling index from start of track) could be fixed
transparently in AmigaDos.  It has no effect upon the reader; no
changes would be required.  Only writes and formats would be changed,
to wait for index before doing their magic.  The old reader and new
readers (identical) would read data written by either writers; in fact
they would have no way to know which type had written them.  The new
writers would not care whether a disk had been used by the old writer,
it would always start the track at the same location anyway.

So the reliability of AmigaDos could be improved by a at most 6%
reduction in overall floppy speed.  What do you say Commodore?
	Charles Brown	charles%hpcvca@hplabs.hp.com