A couple of Bondwell 2 questions

From: Fred Cisin <cisin_at_xenosoft.com>
Date: Mon Nov 6 17:03:46 2000

Tony seems to have stated the answer.

On Mon, 6 Nov 2000, Tony Duell wrote:
> I think you're getting confused as to the 2 types of interleave...
> Physical interleave, which is what Anadisk detects, means that the
> sectors are not 0,1,2,3,... order around the track. The idea is that you
> can read sector 0, process it, and then when you try to read sector 1,
> it's just coming under the R/W head so you don't have to wait for a full
> revolution of the disk. However, each sector has the _correct_ sector
> number in the header, no matter where it is on the track.
> If you use the wrong value of physical interleave when formatting,
> perfomance suffers (you may have to wait a full revolution between
> reading sectors). But files still are read correctly because each sector
> still has the right sector number in the header. Physical interleave is
> _irrelevant_ for normal R/W operations -- it only matters for formatting.

> Logic interleave was used by some CP/M and RT11 systems. This operates at
> a higher level -- you read/write the sectors in the 'wrong' order on a
> track. Suppose ypu have a sisk with no physical interleave at all -- so
> the sectors in order from the index pulse are 0,`1,2,3,... Now, since if
> you try to read those in increasing numerical order you will have poor
> performance, you might instead map :
>
> 0 -> fisrt sector of file
> 2 -> second sector of file
> 4 -> third sector of file
>
> etc.
>
> Now, note that the sector numbers are 'wrong' in the sense that you do
> not read the sectors in increasing numerical order. In this example you
> read sector 2 long before you read sector 1. So you clearly have to know
> the logical interleave table for reading and writing individual files
> (unlike the physical interleave).
>
> It appears to me that logical interleave is a kludge to enable disks
> formatted with the 'wrong' (for performance reasons) physical interleave
> to be used at a reasonable performance without reformmatting. Since the
> DEC RX01 was incapable of reformmatting a disk, it would be sensible to
> use logical interleave to remap the sectors of a 'standard' disk to a
> more suitable order.

There does exist the possibility of designing a file system that could use
different interleaves for different ways that certain file types are
commonly accessed.
 
> AFAIK Anadisk doesn't know anything about Logical interleave -- the
> interleave it detects is the physical interleave determined by reading an
> entire track and seeing what order the sector headers appear. In fact
> it's impossible to determine the logical interleave unless there's some
> known data on the disk -- the only way to determine it is to read said
> data and then work out what order you should have read the sectors in.

As Tony points out, it is trivial to analyze the physical interleave.
Checking the logical interleave is easy IF there is known content.
Checking the logical interleave is easy IF there is a human being looking
at the results.

Writing a program to do it is not very feasible. But you COULD write a
program that would try various possibilities, and then make statistical
comparisons of which ones produced the highest number of correctly spelled
text words (or even grammar checking?), the highest number of valid
instruction sequences, etc. The result would be the ability to report
"what is the most PROBABLE logical interleave". All of which is MUCH
easier to just use a human.


> I would suggest telling 22disk that there is no logical interleave and
> seeing what happens

It is very rare to have BOTH a physical interleave AND a logical
interleave, although such systems DO exist. Having one generally obviates
the need for the other. Although it IS possible, when you find a physical
interleave, it usually means that there will NOT be a logical interleave.

--
Fred Cisin                      cisin_at_xenosoft.com
XenoSoft                        http://www.xenosoft.com
PO Box 1236                     (510) 558-9366
Berkeley, CA 94701-1236
Received on Mon Nov 06 2000 - 17:03:46 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:33:12 BST