Date: Fri, 28 Feb 2014 04:28:37 +0100 From: Polytropon <freebsd@edvax.de> To: Matthias Apitz <guru@unixarea.de> Cc: freebsd-questions@freebsd.org Subject: Re: errors from external USB disk Message-ID: <20140228042837.190f94ad.freebsd@edvax.de> In-Reply-To: <20140227175258.GA3214@La-Habana> References: <20140226121714.GA1532@tiny-r255948> <20140226145527.3cd8eb4b.freebsd@edvax.de> <20140227115934.GA2006@La-Habana> <20140227150715.e6aa0594.freebsd@edvax.de> <20140227175258.GA3214@La-Habana>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Feb 2014 18:52:59 +0100, Matthias Apitz wrote: > El d=EDa Thursday, February 27, 2014 a las 03:07:15PM +0100, Polytropon e= scribi=F3: >=20 > > > While copying big files from the failing disk to another with 'cp -Rp' > > > I saw: > > >=20 > > > Feb 23 18:48:07 La-Habana kernel: (da0:umass-sim0:0:0:0): READ(10). C= DB: > > > 28 00 01 cf d9 cf 00 00 0e 00=20 > > > Feb 23 18:48:07 La-Habana kernel: (da0:umass-sim0:0:0:0): CAM status: > > > CCB request completed with an error > > > Feb 23 18:48:07 La-Habana kernel: (da0:umass-sim0:0:0:0): Retrying co= mmand > >=20 > > So it's definitely a reading error here. >=20 > I was today reading the entire disk with >=20 > # dd if=3D/dev/da0 of=3D/dev/null bs=3D1m >=20 > and after around 700 GByte it terminated with: >=20 > dd: /dev/da0: Input/output error > 712870+0 records in > 712870+0 records out >=20 > in /var/log/messages I have: >=20 > Feb 27 18:01:48 La-Habana kernel: (da0:umass-sim0:0:0:0): READ(10). CDB: > 28 00 57 05 33 80 00 00 80 00=20 > Feb 27 18:01:48 La-Habana kernel: (da0:umass-sim0:0:0:0): CAM status: > SCSI Status Error > Feb 27 18:01:48 La-Habana kernel: (da0:umass-sim0:0:0:0): SCSI status: > Check Condition > Feb 27 18:01:48 La-Habana kernel: (da0:umass-sim0:0:0:0): SCSI sense: > MEDIUM ERROR asc:11,0 (Unrecovered read error) > Feb 27 18:01:48 La-Habana kernel: (da0:umass-sim0:0:0:0): Error 5, > Unretryable error Probably the disk has exceeded its natural life time. :-) > Is there a way, to map away such bad block? Until today I was thinking > that the firmware does this by its own, transparently. You are correct. The firmware maps defective blocks as long as there are spare blocks available. When the problem starts "bubbling up" to the I/O subsystem of the OS, it's usually out of spare blocks, which means that there are more than enough defects. However, some really "bare metal" disk tools, provided by the manufacturer and found on the UBCD, can _sometimes_ help to "re-initialize" the disk and have it live some more time. But what's possible depends on the particular brand and model of the disk. Note that such tools are usually working best when the disk is connected directly (SATA instead of USB). > I have only laptops with USB external. That might be a problem. Maybe there are PCCARD interfaces that expose a "real" SATA port instead of doing SATA<->USB with the described loss of functionality? --=20 Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140228042837.190f94ad.freebsd>