Conference hydra::amiga_v1

>    1) Use DISKDOCTOR
>    2) Use DISKSALVE
>    3) Reformat the partition WORK:

Option 3 is about your only recourse. Make sure it's a low level format so
it will (hopefully) detect the bad spot and wipe it out.

You might want to run DiskDoctor/Salve before formatting just to verify the
integrity of the file system and then back everything up - unless it's quicker
to just re-format and then restore from your originals/backups you have now...

I have the same problem right now in a partition on my hard disk. If only
the A2090a supported SCSI Direct, I could write a quick disk scan program
that mapped out (at the SCSI level) bad blocks... 

<CB>? Will 1.4 (aka 2.0) support newer and better stuff for the A2090a or are
we poor dudes destined to get an A2091?


john

    I've got a 2000HD that came with a A2091.
    
    RE:-1 From the last reply, I take it that if you have a A2091 you
    can let the driver know about bad blocks? I seem to remember reading
    something about that. If so what proceedure should be followed?
    
    
    RE:-2 Does your 2000HD have a A2091?
    
    ... Rich

The A2091 supports a protocol known as SCSI Direct, which means you can 
send SCSI commands directly to devices on the bus. This translates to being
able to read/write blocks in a partition, finding any bad ones, and issueing
a SCSI REPLACE_BLOCKS command which makes the hard disk put the bad block
out of commission. Of course, there are many things to be concerned about
in doing this (like not stepping on the file system etc).

john

Re: .1

> <CB>? Will 1.4 (aka 2.0) support newer and better stuff for the A2090a or are
> we poor dudes destined to get an A2091?

Well, no 2.0 questions, please. ;-)
But this ain't no OS question, anyway. I've asked this question several times
in the past (last time 2 weeks ago on the CBMnet) and got no answer...

We'll have to wait and see (or get an A3000 instead of an A2091 ;-)

<CB>
 

Temporary Fix: When you get a bad file don't delete it.  Rename it
to something like badblock01.  Deleting the file just frees up that
bad block for someone else to use...  When you get several of these
it is time to low level format.

-steve

    
    re .3
    
    	I'm still looking for programming information about SCSI DIRECT.
    Does anyone know the details about SCSI DIRECT ??
    
    
    		Steve
    

�    RE:-1 From the last reply, I take it that if you have a A2091 you
�    can let the driver know about bad blocks? I seem to remember reading
�    something about that. If so what proceedure should be followed?

    The A2091 Installation Software comes with a data verify utility (as
    part of the HDToolbox program - see p.29 of the A2091 manual). When
    run, this will automatically relocate recoverable data from a
    questionable block and then mark the block as bad. If the data is not
    recoverable, then you'd have to restore it from backups. In either
    case, the utility gives you the option of ignoring it or adding it to
    the bad block list.
    
    Pete

How can one determine the cyl/track/offset values of a bad block when a read 
error occurs?

In my specific case I suspect I have marginal bad block that shows up every
so often.  I have a 2090A with 2 ST225's on the ST506 port.  Using CBM's PREP
I can enter bad blocks if I know the cyl/track/offset values.

...Ed

Pretty much by writing a program that scans the blocks of a partition.

This can be done from DOS level by:

	1. Allocate a 1 block file (scratch)

	2. Traverse device list to get starting and ending LBN of partition

	3. read first block of partition and save it in scratch file

	4. write/read partition block some number of times checking
		for errors.

	5. If an error occurs, the block is suspect and should be unlinked
		from the file, a new good block allocated and linked into
		the file and the saved data copied to it. The block in error
		should ideally be mapped out BY THE SCSI DEVICE, but allocating
		it to a "badblocks" file helps. But you lose a block for every
		bad one and there is a "whole" in the logical disk structure.

	6 loop through all blocks in the partition.


This is an on the fly attempt and I'm not sure how well it would work, or even
how long it would take (probably slooow!). 

I'm concerned with #2 (is this info readily available?) and with #5 which could
require quite a bit of knowledge about the file system.

In any case, this stuff belongs  IN THE O/S and the user should NEVER HAVE TO
WORRY about it!

john

Re: .3

>The A2091 supports a protocol known as SCSI Direct, which means you can 
>send SCSI commands directly to devices on the bus. This translates to being
>able to read/write blocks in a partition, finding any bad ones, and issueing

Just a point of information for hackers in the audience:

SCSI Direct does all the things that John promises.  However, you don't
need SCSI Direct if all you want to do is read and write absolute block
numbers on a device.  Merely by opening the device driver (SCSI.device,
overdrive.device, harddisk.device) and sending it absolute read and write
commands you can do the same thing.  See the examples on programming
the trackdisk.device in the ROM Kernal Manual.

Remember, the device driver provides a standard method of accessing the
blocks on a device.  The file system provides a standard set of file
operations by talking to the device driver.  So, if you want to do
non-file I/O to a device, you, like the file system, can access any
block you want through the device driver.

Re: .9

Yes,  the system keeps around all of the information to recreate a
mountlist entry for a device or partition.  To decode the device
list and the file system startup message, you need the AmigaDOS
Manual, or a talent for reading the .h files.

I have a program that given a device name writes out the mountlist
entry for that device.  It does it's work by walking AmigaDOS's
device list.

I wrote it because I was uncomfortable not having mountlist entries
for my partitions on my hard disk (I have an A2091, which doesn't use
mount to mount its partitions).  I was too lazy to construct a mountlist
by hand for the partitions based on the info from the A2091 disk setup
program, so I wrote a program that displayed what the mountlist for
a device would be.

>I have a program that given a device name writes out the mountlist
>entry for that device.  It does it's work by walking AmigaDOS's
>device list.

    Would you care to share that one with your fans? How "safe" is it
    anyway? I'd assume very, since you'd presumably only be reading from
    the forbidden zone (forbidden for those of us with no talent, that is).

    Thanks in advance,

    Pete

Re: .12

I've uploaded the program that writes out a mountlist entry for
any mounted device.  It can be copied from:

	TLE""::UPORT$:[RMEYERS.TRADE.AMIGA]MOUNTLIST.ZOO

I uploaded it using XMODEM.

>	TLE""::UPORT$:[RMEYERS.TRADE.AMIGA]MOUNTLIST.ZOO

>I uploaded it using XMODEM.


Thanks Randy! 

john

    Hello all. (recycling an old note...good for the environment:-))
    
    I have an A2000 with a Wren III SCSI drive connected to an A2090A
    that is having problems.  Read/Write erros showed up on one of my
    partitions.  I backed the partition up, performed an AmigaDOS 1.3
    FORMAT command, and restored the partition.
    
    Well...new errors have appeared.  I purchased my system second
    hand and was wondering if anyone knew if the A2090A ``prep''
    command does a low-level format and will clear up these problems.
    I just want someone to tell me it might do some good before I go
    through the hassle of a full disk backup/restore.  160Mb drives
    aren't alot of fun when those need to be done .. :-)
    
    If ``prep'' won't do the trick does anyone have any suggestions?
    I know the A2091 HDtoolbox wont work because the A2090A doesn't
    use the RigidDiskBlock.  Any PD tools out there to help?
    
    Thanks,
    George
    

    The A2090A will not do a low level format, in fact you can't low level
    format a SCSI drive.  You can use Quarterback tools to map out bad
    blocks.
    
    Jean
    

    Thanks for the reply.  So re-PREPing wouldn't do anything?  
    I've looked at Quarterback Tools before but haven't had 
    the money lately...it seems I've got to find the money
    now. :-(
    
    Thanks,
    George
    

There is also a program called No-errors that will map out bad spots.  It 
enters any bad spots it finds as a file.  The down side is it did not work on 
the ICD controller I have as it hangs on a disk errors.  You can also take the 
poor mans approach and that is rename any file with a bad spot to something like
BAD_SPOT_NUMBER_x.  Then set the A and clear the RWED protection bits.  This
could waste a lot of disk space.  And any time you reformat you release these
bad spots for usage again.

If the errors keep cropping up look into a hardware problem.

Noerrors was on EOT::

Alan

    re .16
    	The GVP controller,and FastPrep WILL do a low level format of a 
    SCSI disk. I always thought that scsi handled this bad block thing
    as one of it's functions. I have had times when I messed around with
    my scsi disk, and had to do a low level format. Repreping with the
    GVP simply rewrites the home block on the drive. I don't know how the
    A2090A does it.
    								bill

    I believe it's the drive that determines what happens during the format
    operation.  The controller simply issues a "format yourself" command,
    then the drive does its thing (which may be as simple as 'remembering'
    that it just forgot everything, or actually going out and scribbling in
    all the blocks) and returns a completion status.

re .20

Exactly correct. What a drive does, or *can* do, with a FORMAT command
depends on it's internal design.

There are basically 2 methods of laying out and finding sectors on the 
media in use today: Dedicated Servo and Embedded Servo (well, really 3 methods -
some drives use both dedicated and embedded).

A dedicated servo is a scheme which allocates an entire surface for servo
information.

An embedded servo system has servo information at each sector on all surfaces.

There are benifits and drawbacks to each system which I won't go into here.

A FORMAT traditionally rewrites all data AND the sector headers (ID fields etc)
This is doable on dedicated systems, but on embedded systems the servo stuff 
must be written in a very precise, controlled environment, so a FORMAT cannot
rewrite servo data.

The SCSI FORMAT command has many options for doing defect mapping/scanning. 
Typically, a FORMAT will write the DATA fields in all sectors and set up
the DEFECT LIST on the drive (SCSI drives maintain a defect list). Some 
drives only manage the defect list on FORMAT so the FORMAT operation can 
take from a second or two to an hour or more...

hope this vague description helps...

john