From owner-freebsd-stable@FreeBSD.ORG Sat Aug 20 06:43:38 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A530106566C for ; Sat, 20 Aug 2011 06:43:38 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 0501A8FC13 for ; Sat, 20 Aug 2011 06:43:37 +0000 (UTC) Received: from digsys236-136.pip.digsys.bg (digsys236-136.pip.digsys.bg [193.68.136.236]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p7K6hO2n009616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Aug 2011 09:43:30 +0300 (EEST) (envelope-from daniel@digsys.bg) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Daniel Kalchev In-Reply-To: <20110820032438.GA21925@icarus.home.lan> Date: Sat, 20 Aug 2011 09:43:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <65623662-0232-4599-B633-6D207A4CF15A@digsys.bg> References: <1B4FC0D8-60E6-49DA-BC52-688052C4DA51@langille.org> <20110819232125.GA4965@icarus.home.lan> <20110820032438.GA21925@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1244.3) Cc: freebsd-stable@freebsd.org, Dan Langille Subject: Re: bad sector in gmirror HDD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 06:43:38 -0000 On Aug 20, 2011, at 06:24 , Jeremy Chadwick wrote: > You might also be wondering "that dd command writes 512 bytes of zero = to > that LBA; what about the old data that was there, in the case that the > drive remaps the LBA?" If you write zeros at OS level to an LBA, you will end up with zeros at = that LBA. What else did you expect??? The already remapped LBAs in ATA are not visible anymore to the user/OS. = You get a perfectly readable sector. Of course not at the original = location, but as you confirmed we are done with CHS addressing. The pending bad sectors are almost always 'corrected', that is, remapped = when you write to that LBA. So your script will find only one readable sector and that will be the = sector that is pending reallocation. It may be that writing zeros to all free space, like dd if=3D/dev/zero of=3D/filesystem/zero bs=3D1m; rm /filesystem/zero is enough to remap the pending bad block and not have any unreadable = sectors. But if the unreadable sector is in a file or directory -- bad = luck -- these will need to be rewritten. Once upon a time, BSD/OS had wonderful disk 'repair' utility. It could = detect failing disks by reading every sector (had nice visual), or could = re-write the drive by reading and writing back every sector. On bad = blocks it would retry lots of times and eventually average what was read = (with error). Having said that, I doubt modern ATA drives will let anything be read by = the pending bad block, but.. who knows. Daniel