Date: Sun, 21 Jan 2007 18:56:18 -0500 From: Jason Harris <jharris@widomaker.com> To: "Tuc at T-B-O-H.NET" <ml@t-b-o-h.net>, "Kenneth D. Merry" <ken@kdm.org> Cc: freebsd-scsi@freebsd.org, Poul-Henning Kamp <phk@freebsd.org> Subject: Re: Camcontrol not changing modepage Message-ID: <20070121235617.GA29188@wilma.widomaker.com> In-Reply-To: <20061113224217.GA94669@nargothrond.kdm.org> <200611131836.kADIaYdh077142@himinbjorg.tucs-beachin-obx-house.com> References: <20061113195311.GA85979@nargothrond.kdm.org> <200611132222.kADMMiAG081205@himinbjorg.tucs-beachin-obx-house.com> <20061113224217.GA94669@nargothrond.kdm.org> <200611131836.kADIaYdh077142@himinbjorg.tucs-beachin-obx-house.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 13, 2006 at 01:36:34PM -0500, Tuc at T-B-O-H.NET wrote: > I have a disk thats doing : >=20 > 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= =20 > > da0: 1.000MB/s transfers > > da0: 3999MB (8191998 512 byte sectors: 255H 63S/T 509C) > >=20 > > 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 see= ms > to support write reallocation, that should allow it to remap that sector, > and the rest of the drive should be useable.=20 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. >=20 > 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=3D1 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! --=20 Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it? jharris@widomaker.com _|_ web: http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004 --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iJ0EARECAF0FAkWz/aFWGGh0dHA6Ly9rZXlzZXJ2ZXIua2pzbC5jb206MTEzNzEv cGtzL2xvb2t1cD9vcD1nZXQmc2VhcmNoPTB4RDM5REEwRTMmd2VoYXZleW91bm93 PXRydWUACgkQSypIl9OdoOPNhQCgqberUDmcfERcuP6WI6GgyDzQxsMAni5x4cdx gdaRe12FjZmJlFgrJau9 =EXjL -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070121235617.GA29188>