Conference hydra::amiga_v1

re         <<< Note 4603.0 by ULTRA::BURGESS "Mad Man across the water" >>>
>              -< Anyone have problems with DiskSpeed on DH7: ?? >-

	Maybe I can ask it some other way(s)....


	Will someone else with an RZ23 on a GVP Series II card  PLEASE 
	run DiskSpeed 3.1 on DH7: and report their success or failure ?



	or...

	Does anyone know of any weird problems with FFS when lots of 
	zero length files are created ? 

	...and

	  Is any of this weirdness more likely to show up on the last
	partition ? 

=======================================================================

	Last night I 

i)	Ran DiskSpeed until the first error.  

ii)	Re-booted, and re-named the  DH7: Disk Test Directory to
	something else, leaving all the zero length files in it. 

	repeated i) & ii) above, each time using a different directory 
name - got up to 5 renamed test directories with 1 to "very many" zero 
length files in them.  The problem remained.


	Reg

Re: .1

>	  Is any of this weirdness more likely to show up on the last
>	partition ? 

Frequently strange problems will show up with the last partition if
you have the drive geometry wrong.  Are you sure you have the right
number of heads, tracks, and blocks per track right?

Personally, I've not encountered any bugs in the fast file system
except that some versions of it poke a value in the memory location
zero upon startup.  This causes some buggy programs that depend on
location zero being zero to fail.

re                <<< Note 4603.2 by TLE::RMEYERS "Randy Meyers" >>>
>                             -< Correct geometry? >-

> Frequently strange problems will show up with the last partition if
> you have the drive geometry wrong.  Are you sure you have the right
> number of heads, tracks, and blocks per track right?

	Thanks Randy,

	I think Faaastprep just gets what it gets from the drive's 
ROMs (maybe EEPROMs).  It says 8 heads, 33 sectors, 775 cylinders, 
i.e. 104.xx Mbytes - but in another box it says its a 99 Meg drive, 
so I've been assuming that ~5% is held back for bad block mapping...???

	I don't know much about the "guts", but a little arithmetic 
seems to indicate that it doesn't reserve one head/surface for servo, 
that would bring it down to ~91.6 Meg.   5 Meg for bad blocks would 
represent about 40 cylinders (though they probably scatter the spare 
blocks around) and there are only 7 left if I create 8 partitions of
12 Mbytes    

	......sounds like I may need smaller partitions to get around 
Faaastprep seeing 104 Mbytes "total"  but not leaving enough of it for
bad block mapping, even though it reads the ROM (EEPROM) that says
99Mbytes..... 

	I'll check the arithmetic and try a better fit tonight,

	Thanks again, I think your clue will get me a lot further.

	Reg

    Reg,
    I don't believe that 1.3 reserves any part of the drive for bad blocks,
    unless you do that yourself.  However DIGITAL does, if I remember
    correctly.  You may also be running into problems with GVP drivers. 
    For instance GVP AT PROMS only support 1 kind of driver if the drive is
    at or above 200MB.  GVP claims that the drive manufacturers don't
    conform with AT specs, ALL the manufacturers say GVP is crazy and can't
    write drivers.  Finger pointing is everywhere.
    
    DH7:?  Did you try to use a different name for this partition?  I have
    had some controllers (actually drivers) get confused when you use a
    physical declaration for a logical partition.  Have you tried something
    innoculous, like WIDGET: for the partition name?
    
    Try partitioning at a 10MB size for each one and see if you
    can get 8 partitions.
    
    Lastly, some controllers have trouble above a certain cylinder size. 
    (Read that as cylinder COUNT.)
    
    Topgun

re                 <<< Note 4603.4 by SDOGUS::WILLIAMS "TOPGUN" >>>
>              -< Put away your blocks and get out your cylinders >-

>    Reg,
>    I don't believe that 1.3 reserves any part of the drive for bad blocks,
>    unless you do that yourself.  However DIGITAL does, if I remember
>    correctly.  You may also be running into problems with GVP drivers. 

	Thanks, "TOPGUN"

	Yes,  DIGITAL does - apparently at the drive level.  
FaaastPrep seems to use the device's physical geometry (33 x 775 x 8) 
to conclude that it's a 104.x Mbyte drive  *_DESPITE_*  the fact that 
it reads that its 99 Mbytes from (I think) the drive's EPROM.  It also 
seems to start the next partition on the next cylinder boundary, 
though I'm not sure what happens to any left over sectors at the end 
of a partition when it does its rounding up.

	SPECULATION:

	What I think happens is that the test runs and the DRIVE gets
a read error.  It tries to dynamically (and invisibly to the GVP card,
device driver, FFS, DiskSpeed or Amiga) remap the sector to one of the
~10,000 spare blocks.  If there aren't any left it decides that the
error is irrecoverable, so it passes back some sort of an error
code/signal.  If FaaastPrep has allocated all or very nearly all of
what the drive thinks should be the spare block space to the last
partition things go WHACKY.  If I knew more about the mapping of
logical to physical block numbers to head/sector/cylinder numbers,
i.e. "layout" I could guide my experiments with more wisdom. 
The fact that this drive became available to me AT ALL might 
have some connection with its history - i.e. it might well have come
from a pile that was once marked  "flakey"  (-:, (-: 

>    For instance GVP AT PROMS only support 1 kind of driver if the drive is
>    at or above 200MB.  GVP claims that the drive manufacturers don't
>    conform with AT specs, ALL the manufacturers say GVP is crazy and can't
>    write drivers.  Finger pointing is everywhere.

	RZ 23 is a SCSI drive, so I'm assuming that this doesn't 
affect me  - -  you're using  "AT"  as a drive type, right ?
    
>    DH7:?  Did you try to use a different name for this partition?  I have
>    had some controllers (actually drivers) get confused when you use a
>    physical declaration for a logical partition.  Have you tried something
>    innoculous, like WIDGET: for the partition name?

	No, but I might try it at some point.

	I havn't noticed if the errors only happen when I explicitly
tell DiskSpeed to use DH7:  vs  just letting it run on the partition
its in  - -  which just happens to be DH7: 

>    Try partitioning at a 10MB size for each one and see if you
>    can get 8 partitions.

	I'm currently down to something like 4 x 11 Mbytes and 4 x 12
Mbytes - don't remember exactly, except the last cylinder number is 
728, so the total assigned to partitions is < 99 Mbytes.  This seems to 
work.

>    Lastly, some controllers have trouble above a certain cylinder size. 
>    (Read that as cylinder COUNT.)

	Its a Series II GVP, i.e. "contemporary design".  I'd hope 
that it knows enough to go up to the >1,000 cylinder counts that I've 
heard (with considerable envy) that other folks have.  Someone in here 
claims to have had an RZ 5x running on (external to ?) just such a card
at home for a while. 

>    Topgun

	Thanks again, my conclusion at this point is what I said above 
PLUS a suspicion that the drive might be close to running out of spare 
blocks  - -  assuming it has bad block re-mapping somewhat along the 
lines I described.  If this proves to be the case I might be forced to 
decrease the partition size(s) over time  -  if it gets worse.  I may 
also discover whether this makes a difference or if the spare block 
allocation algorithm isn't  "Whatever is left after the partitions are 
allocated".   If I had a critical mission for the Amiga I'd probably 
just go out and  *_BUY_*  a new and guaranteed drive.

	Reg

Re: .5  (Bad Block Replacement on SCSI drives)

I've read the detailed technical information of three SCSI drives:
a Fuji 50 Meg, a Seagate ST-157n 48 Meg, and a Quantum 105 Meg.  All
three handled bad block replacement in a similar manner.

The drive reserves a certain number of blocks at the end of each cylinder
or track for bad block replacement (at least one of the three drives did
this on a per cylinder basis and at least one did this on a per track basis).
Once one of the blocks on a cylinder was identified as bad, the drive would
automatically redirect any read or write of that block to the designated spare.

Remember, SCSI devices are intelligent devices.  I/O is done to a SCSI
device in terms of block numbers, not tracks, sectors, or head numbers.
The host system need not know anything about the real geometry of the
drive.  So, it is immaterial to the host system where the SCSI disk puts its
bad blocks.  In fact, the Quantum drives take advantage of the fact that
you can store more information near the rim of the disk than near the
center because the outside  tracks have a longer circumference.  The
Quantum drives are divided into zones where all of the cylinder within
the zone have the same number of blocks per track, but the outer zones
have more blocks per track than the inner ones.

The important number for dealing with a SCSI device is the number of
"guaranteed number of accessible blocks."  This is the number of blocks
on the disk minus the number of reserved blocks for bad block replacement.

AmigaDOS is written to deal with non-SCSI devices, and so it wants a
description of disks in terms of number of heads, number of tracks,
number of blocks per track.  However, when dealing with a SCSI device,
that information is used by AmigaDOS to do two things:

    1.	Figure out the number of blocks on the device (number of heads
	times the number of tracks times the number of blocks per track).

    2.	Place the root directory at the center of the disk to minimize
	the distance of random seeks from the root to blocks on the disk.

AmigaDOS, and the drive itself, is perfectly happy if you use any numbers
for the geometry that do not exceed the total number of guaranteed accessible
blocks.

I, myself, have taken advantage of the above fact, and used widely different
geometries for the same drive as it suited my convenience.  I've even
used 1 head by 1 track by 20 Meg blocks per track and the drive performed
just fine (this was before the Rigid Disk Block standard reserved the
first cylinder of the drive).  Upon getting a new drive, I would find the
prime factors of the number of guaranteed accessible blocks, and invent
a geometry that allowed me to partition the drive to my taste.  One of the
things I would do was come up with a geometry where a cylinder contained
100 to 200 blocks.  This minimized the space lost due to cylinder zero
being reserved for the Rigid Disk Blocks.

I seem to remember that the Fuji drive and the Seagate drive returned
the physical geometry of the drive when asked.  If you used that
geometry as the AmigaDOS geometry you were screwed because it implied
a greater number of accessible blocks than were available.  My
Quantum returns a geometry that does not match the physical geometry
of the drive.   Instead, the numbers are similar to a lot of other
drives, and when multiplied together do not exceed the number of
guaranteed accessible blocks on the drive (in fact, the product is a hundred
blocks or so too small).  Quantum probably took this approach since
the physical geometry of the drive can not be described in three
numbers because of the use of zones with different numbers of blocks
per track.

When you AmigaDOS formatted the partitions, did you do a full format of
the last partition or a quick format?  The full format writes then reads
each track; the quick format just writes the root blocks in the center
of the partition.  I seem to remember when I had the Fuji, that a full
format would fail on the last partition when it exceeded the number of
guaranteed assessable blocks on the drive.  If so, you could do a full
format of the last partition and read the number of the first
non-accessible block from the FORMAT error message.  Once you have that,
you can adjust the number of tracks in the drive geometry so that
AmigaDOS doesn't think the drive is bigger than it is.  Alternatively,
you could take the advertised capacity of the drive, and pick
three numbers that when multiplied do not exceed that capacity.

----------

A fun fact about bad block replacement: I mentioned that a few blocks
are set aside in every cylinder or track for the bad block replacement.
Those blocks are for the exclusive use of replacing blocks in that
same cylinder or track.  Thus, if you have four blocks reserved in a
cylinder for bad block replacement, and a cylinder with five bad
blocks, the drive will not be able to perform bad block replacement
for the fifth bad block.

I guess at that point, you would re-partition the disk so that the bad
block fell into a dead space between partitions.

> 
> A fun fact about bad block replacement: I mentioned that a few blocks
> are set aside in every cylinder or track for the bad block replacement.
> Those blocks are for the exclusive use of replacing blocks in that
> same cylinder or track.  Thus, if you have four blocks reserved in a
> cylinder for bad block replacement, and a cylinder with five bad
> blocks, the drive will not be able to perform bad block replacement
> for the fifth bad block.
> 
> I guess at that point, you would re-partition the disk so that the bad
> block fell into a dead space between partitions.
> 

Ahh,that's not true anymore. Many new devices have much more complicated 
replacement algorithms. For example, if they run out of spare on a track,
they will get one from the next track (here head == track), if they run out
of spares on the entire cylinder, they will get one from the next cylinder
etc. 

The idea is to not die when a bunch of bad spots are found in one area
(typical) and to minimize the time required to get to the spare. 

john

Re: .7

>Ahh,that's not true anymore....  if they run out of spare on a track,
>they will get one from the next track...

I should have guessed that this was coming, since it does make a lot of
sense.  I wonder if the newer Quantums are doing this yet:  I bought my
ProDrive 105S about two years ago when the drive just came out.  It didn't
allow replacement blocks to come from another cylinder.

re         <<< Note 4603.7 by STAR::GUINEAU "but what was the question?" >>>
>                        -< modern stuff can handle it >-
> Ahh,that's not true anymore. Many new devices have much more complicated 
> replacement algorithms. For example, if they run out of spare on a track,
> they will get one from the next track (here head == track), if they run out
> of spares on the entire cylinder, they will get one from the next cylinder
> etc. 

	Thanks John, I thought I'd read something along these lines,
but I may have wishdreamed it.  Two questions suggest themselves;

i)	How smart is the RZ 23 in this regard ?

ii)	Does the  "get one from the next track, else get one from the 
	next cylinder"  algorithm wrap around to track and cylinder
	zero when bad spots are found in the high cylinder numbers ?, 
	i.e. would the RZ23 look for spares on cylinders  
	773 -> 774 -> 775 ->0 -> 1 ->     etc. ? 
	I realize it would have to give up at complete wrap around, but
	the high numbered cylinders seem to need as much back up as
	the low numbered ones. 
	If it chokes at 775 thats probably what I'm seeing symptoms 
	of.

	Reg

> 
> i)	How smart is the RZ 23 in this regard ?

I believe it has a algorithm which zigzags back and forth around the
error block (lower track, cylinder, higher track, cylinder) until it finds 
one. The idea here is to minimize seek length worst case.

> 
> ii)	Does the  "get one from the next track, else get one from the 
> 	next cylinder"  algorithm wrap around to track and cylinder

Not sure. I doubt it since that would be a big hit in time to get to the
replacement block. I would think they search backwards till they find a good
one.


If your disk is that bad that it runs out of spares within a few cylinders,
its probably trash anyway.

john