srg@quick.COM (Spencer Garrett) (04/07/90)
The number of sectors per track on a Wren V (94181-702) is not constant. There are more sectors on outer tracks than inner tracks. The Berkeley Fast File System insists upon a figure for SPT, and is only prepared for a single constant. The best way to deal with this problem, IMHO, is to lie to the partitioning program. A read capacity command reports 1173930 sectors total, which happens to be 2 * 3 * 5 * 109 * 359. I use 3 * 5 = 15 heads (just happens to be true, not that it matters) 2 * 359 = 718 cylinders 109 sectors per track
steve@nuchat.UUCP (Steve Nuchia) (04/09/90)
In article <7820@quick.COM> srg@quick.COM (Spencer Garrett) writes: >The number of sectors per track on a Wren V (94181-702) is not >constant. There are more sectors on outer tracks than inner tracks. >The Berkeley Fast File System insists upon a figure for SPT, >and is only prepared for a single constant. The best way to >deal with this problem, IMHO, is to lie to the partitioning If you want absolute best performance and don't mind (or maybe even want) having the drive partitioned, the best way to handle this is to tell mkfs the truth, which requires having partitions starting at or near the points where the SPT steps occur. For that to work you have to know where that happens and compute a set of head/cyl/spt figures from which you can back out fake cylinder numbers to feed to the partitioning software. Then tell mkfs the real info for each partition. Even that may be pointless if the embedded controller deals with errors by slipping all subsequent sectors. By the time you get to the middle of the disk your cylinder boundaries are hopelessly scrambled. I noticed that Adaptec's ST-506 slave controller has an option to reserve a number of sectors per cylinder, so the cylinder allignment won't be disturbed for more than a cylinder or two. This beats the SMD method of slipping one sector per track. Anybody know if any embedded scsi drives handle errors this way? -- Steve Nuchia South Coast Computing Services (713) 964-2462 "The study of the art of motorcycle maintenance is really a miniature study of the art of rationality itself. Working on a motorcycle, working well, caring, is to become part of a process, to achieve an inner peace of mind. The motorcycle is primarily a mental phenomenon." -- Robert M. Pirsig
russell@labtam.oz (Russell McDonell) (04/10/90)
steve@nuchat.UUCP (Steve Nuchia) writes: ]In article <7820@quick.COM> srg@quick.COM (Spencer Garrett) writes: ]>The number of sectors per track on a Wren V (94181-702) is not ]>constant. There are more sectors on outer tracks than inner tracks. ]>The Berkeley Fast File System insists upon a figure for SPT, ]>and is only prepared for a single constant. The best way to ]>deal with this problem, IMHO, is to lie to the partitioning ]If you want absolute best performance and don't mind (or maybe ]even want) having the drive partitioned, the best way to handle ]this is to tell mkfs the truth, which requires having partitions ]starting at or near the points where the SPT steps occur. This DOES NOT WORK - see below. ]For that to work you have to know where that happens and ]compute a set of head/cyl/spt figures from which you ]can back out fake cylinder numbers to feed to the partitioning ]software. Then tell mkfs the real info for each partition. The information about where the spt changes is available from the read block limits command (read number for this zone, read first block of next zone, repeat until end of disk). But this will not help you. All you find out is that you have an unsoluable problem that the controller has already solved. The reason is because of the bad sector handling technique in these drives. These drives allocate (say) 46 sectors per track on the first 14 heads and 44 data sectors on the last head. Thus 2 sectors are reserved for bad block mapping per cylinder. Now that means that the number of sectors per cylinder for this zone is 14*46+44 (for example), which often does not have any factors and certainly cannot be represented as 15 heads and 45.x sectors per track. Even if, as you can in this example you pretend that there are 43 sectors per track and 16 heads, you still do not get optimal performance because head switching would not take place at the points the filesystem would expect. The filesystem code just cannot cope with the case where sectors per track is not the same on all tracks within one cylinder. ]Even that may be pointless if the embedded controller deals ]with errors by slipping all subsequent sectors. No they don't - see above ]I noticed that Adaptec's ST-506 ]slave controller has an option to reserve a number of sectors ]per cylinder, so the cylinder allignment won't be disturbed ]for more than a cylinder or two. This beats the SMD method ]of slipping one sector per track. Actually it isn't. The cylinder alignment is never disturbed. If more that 2 sectors go bad on a cylinder then a whole track is mapped to a track on one of the 2 reserved inner cylinders of the drive. NOTE:sector slipping is wasteful, but it guarantees a fixed number of sectors per track and a fixed number of tracks per cylinder. Thus the head switching time and head stepping times can be used for planning optimal layout of the disk. With WREN drives this is not the case. Further more these drives can re-order reads (I want 8 consecutive blocks which happen to be on two different cylinder - the drive will read them in the order it thinks is optimal) and they can also cache recent reads/writes. So you have your Unix cache, which assumes no cache on the drive, trying to optimise disk operations when in reality you are only copying to/from the disk's on_board cache. This can do horrible things to you efficiency algorithms. We decided that the basic answer was give up. (So did the people at Berkeley the last time we asked them about this).