Path: utzoo!attcan!uunet!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.sys.amiga.tech Subject: Re: Request to Commodore (Bad Blocks) Keywords: trackdisk.device Message-ID: <4816@cbmvax.UUCP> Date: 23 Sep 88 21:55:19 GMT References: <8891@cup.portal.com> <5660018@hpcvca.HP.COM> <40244@linus.UUCP> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Organization: Commodore Technology, West Chester, PA Lines: 43 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