Camcontrol not changing modepage

[Jason Harris]

On Mon, Nov 13, 2006 at 01:36:34PM -0500, Tuc at T-B-O-H.NET wrote:

> 	I have a disk thats doing :
> 
> THE FOLLOWING DISK SECTORS COULD NOT BE READ: 1131461,

Was this happening when reading/writing a specific file or directory,
running an fsck(8), or something else?  What type of filesystem?
(It sounds like the drive was still mountable (and mounted), correct?)

On Mon, Nov 13, 2006 at 03:42:17PM -0700, Kenneth D. Merry wrote:
> On Mon, Nov 13, 2006 at 17:22:44 -0500, Tuc at T-B-O-H.NET wrote:

> > umass0: Generic Mass Storage Device, rev 2.00/1.41, addr 2
> > da0 at umass-sim0 bus 0 target 0 lun 0
> > da0: <JetFlash TS4GJF2A/120 8.07> Removable Direct Access SCSI-2 device 
> > da0: 1.000MB/s transfers
> > da0: 3999MB (8191998 512 byte sectors: 255H 63S/T 509C)
> > 
> > 	USB pendrive......

> > 	I was hoping it would "try" to move it, and mark it bad so I can
> > atleast continue to use it as is. If something was destroyed, atleast I
> > can get the rest of the information.

Did you try to tar/cpio/pax/dump the mounted fs?  Do/did they die when
hitting bad sectors?

> Your best bet is to write to that individual sector.  Since the drive seems
> to support write reallocation, that should allow it to remap that sector,
> and the rest of the drive should be useable. 

What is the best/safest way to do this?  How does this affect the
file/directory/inode which resides on the bad block?

> One way to try to pull all of the accessible data off the drive is phk's
> 'recoverdisk' program, located in /usr/src/tools/tools/recoverdisk.
> 
> It will pull as many blocks as it can off the drive.

The manual page says it "reads data from the special file until all
blocks could be successfully read."  Thus, wouldn't this one bad
block/sector leave a (sparse) hole in the image it creates
(and require a ^C to stop recoverdisk), assuming the [p]read(2)
always returns EIO?

> You could pull off as many blocks as you can into a file that is an image
> of the drive, and then dd that image back over the drive itself.

Writing a block of zeroes over the unreadable sector?  Does this
simply/correctly clear an inode, zero out part of a file, make
any files where st_nlink=1 in a directory unusable/unallocated,
or make the fs use alternate superblocks, as appropriate?

Assuming a ufs fs, would all the unallocated inodes/files be
recoverable (to ./lost+found) by fsck?  (Would an mdsdos fs
fare any better, or worse?)

Sorry for all the questions, but I just finished a program that
stat(2)s a list of files and read(2)s as much as it can of each
file.  If a bad sector does cause EIO, I suppose reporting that
immediately would help find such (blatant) media errors.  Since
it doesn't read special files, I assume using phk's recoverdisk
strategy of 512B reads will just give me a bit more of the file
beyond the last good 64kB chunk/read.  As this can only benefit
my application, I'll go ahead and implement it and hope I don't
have a good way to test it except maybe on old, unwanted floppy
disks.  Thanks, phk!

-- 
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
jharris at widomaker.com _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 313 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-scsi/attachments/20070122/cedd9b86/attachment.pgp