Path: utzoo!mnetor!uunet!husc6!necntc!necis!mrst!sdti!mjy
From: mjy@sdti.UUCP (Michael J. Young)
Newsgroups: comp.sources.bugs
Subject: Re: Bugfix/Questions re fsanalyze
Message-ID: <205@sdti.UUCP>
Date: 27 Jan 88 17:22:04 GMT
References: <253@mybest.UUCP>
Reply-To: mjy@sdti.UUCP (0000-Michael J. Young)
Organization: Software Development Technologies, Sudbury MA
Lines: 31
Keywords: interblock gap, broken

In article <253@mybest.UUCP> paddock@mybest.UUCP (Steve Paddock) writes:
>I'm not at all sure, but I suspect that I have found a bug in
>fsanalyze, recently posted to comp.sources.misc.  
>
>To demonstrate the bug, mkfs a file system where the gap cyl
>information is specified on the command line; in specific, for a 
>CDC Wren II in a 3B2 this is 9 162, representing interblock gap
>of 9 x 512 byte blocks and 162 blocks/cylinder.

Hmm. I don't quite understand this one.  My file systems were generated
with an interblock gap of 2, and I don't see this behavior.  Blocks are
still allocated sequentially.  I didn't think the interblock gap affected
block numbers, per se, but just their mapping onto physical disk sectors.

For example, with a gap of 2, I thought the block/sector mapping would
be something like (assuming 15 sectors per cylinders to make things work out):

   Physical Sector #: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14
   Logical Block #  : 0  5 10  1  6 11  2  7 12  3  8 13  4  9 14

It sounds like you're saying that logical block numbers map directly onto
physical sectors even if there is an interblock gap:

   Physical Sector #: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14
   Logical Block #  : 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14

Which is right?
-- 
Mike Young - Software Development Technologies, Inc., Sudbury MA 01776
UUCP     : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy
Internet : mjy%sdti.uucp@harvard.harvard.edu      Tel: +1 617 443 5779