🚀 go-pugleaf

In article <40244@linus.UUCP> eachus@mitre-bedford.arpa (Robert I. Eachus) writes:
>      This is the  key insight.  Writes  can be coupled  to the  index
>pulse, and  disks written by a  "smarter" trackdisk.device can be read
>(and written  to) by  an   old  trackdisk.device with  NO compaibility
>problems.

	This is correct.

>>We gave up track reliability for at best a 7% increase in overall
>>floppy speed.

	No, we gave it up for at best a 33% increase in speed (for
writes: (1.5-1.0)/1.5 by your way of calculating, 50% (1.5-1.0/1.0)).
Also, read vs write percentages aren't probablistic, since usually you're
writing something or reading something, rarely both simultaneously.
(ignoring the requirement to read a track in order to write it).

>     Not quite, Charles, adding  track reliablity won't cost even that
>much. Right now, trackdisk.device must rewrite an entire track even if
>only  one sector is   changed, and more  important  must  read a track
>completely to write one  sector.

	True, you must currently read a track before writing it.

>  If a "smart" trackdisk.device knows
>where sectors  are located,  it  can do  single  sector writes  in  an
>average of 0.7 rotations,  instead of 2.2.

	No, because the inter-sector gaps are not large enough to support
this (which is also why we can squeeze 880K onto a floppy, instead of
720k (11 sectors/track/side, vs 9)).  If we cut down the storage to
720K, we could do that (which is how we read/write IBM disks now).


	Now, assuming we were to lock writes to the index (I'm not saying
that we will).  What would be the hard advantages (precisely)?  Remember,
trackdisk is unlikely to do badblock mapping, since it has no spare
blocks/tracks to play with, and must support both SFS and FFS and anyone
else who uses it.  Are there any advantages other than DiskSalv being
slightly better at recovering files on a disk with errors?

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup