Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!elroy!orion.cf.uci.edu!ucsd!rutgers!mailrus!cornell!uw-beaver!microsoft!w-colinp
From: w-colinp@microsoft.UUCP (Colin Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: Faster File Systems
Message-ID: <119@microsoft.UUCP>
Date: 21 Dec 88 09:47:32 GMT
Reply-To: w-colinp@microsoft.UUCP (Colin Plumb)
Organization: Microsoft Corp., Redmond WA
Lines: 26
Confusion: Microsoft Corp., Redmond WA

Since this design I'm working with is completely track-based, it's easy to
tell if there is any data I'm interested in on a track.  If there isn't,
I don't really need to read the track before writing it, saving considerable
time.

It appears that trackdisk.device always reads in a track before writing it,
even if it has a full track's worth of data, so I'd have to use the
forbidding-sounding ETD_FORMAT (since I use the header label area).

However: it is, I suppose, possible for a disk drive to mis-seek.  I seem to
recall the number "1 in 10^6" used in some related connection on a floppy
spec sheet.  Is it, in fact, a Bad Idea to write without looking first?

It's an awfully tempting performance optimisation.... If I buffer it
properly, most of a copy of a large file can be done this way.

(Another problem is that, if I do blind writes, I had better be pretty darn
sure the track *is* empty, and it's not just that I didn't update the free
list since writing to it.  But this, I know how to handle.)

Question: I though that the trackdisk.device read both sides of a cylinder
when doing a track read.  But now that I look, I can't find evidence either
way.  Does it read one or two sides?

Thanks for any hints!
-- 
	-Colin (uunet!microsof!w-colinp)