From owner-freebsd-fs Wed Oct 31 9:52:12 2001 Delivered-To: freebsd-fs@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id AE83737B401 for ; Wed, 31 Oct 2001 09:52:08 -0800 (PST) Received: from dialup-209.247.137.200.dial1.sanjose1.level3.net ([209.247.137.200] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 15yzWv-0002vC-00; Wed, 31 Oct 2001 09:51:58 -0800 Message-ID: <3BE03A6B.33F1D15B@mindspring.com> Date: Wed, 31 Oct 2001 09:52:43 -0800 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Byan, Stephen" Cc: "'bv@wjv.com'" , Alexander Leidinger , bde@zeta.org.au, julian@elischer.org, fs@FreeBSD.ORG Subject: Re: physical block no -> name of file (FFS)? References: <378289F42B3FD51185AD0002B3302CF4091C7C@mmaexc01.mma.maxtor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org VERY nice article, Stephan! We should capture this somewhere as a reference work (like the handbook, as oppose to just the list archives). Two comments: 1) You can _want_ to disable automatic relocation; this is most common when you set up spindle sync in order to make virtually taller platter stacks. In early FreeBSD, Rod Grimes did this for SCSI. "Byan, Stephen" wrote: > Theoretically, all media faults have been mapped out during the drive > manufacturing process, and there should be no "grown" defects, so in most > cases the source of the uncorrectable read error is data that was written > off-track, or interference from data for a neighboring track that was > written off-track. (Note that both of these are rare occurances, and that > drives take special care to verify that the head is in the right place > before and after writing, and will retry the write if the head moved > off-track during the write. But in rare cases, external shock or vibration > could force an off-track write. Don't kick the mainframe equipments :-) In > this case, rewriting the sector without reassigning the LBA to a spare is > the correct recovery action. 2) The most common case I have seen for this is "multimedia" drives. The reason for this is that it is (was?) very common for companies building "multimedia" drives to intentionally disable thermal recalibration, since this could result in a "hiccup" when recording from a live source. This is, IMO, the most common cause of off-track reads or writes. One of the first things I used to do once these drives became cheaper than other "non-multimedia" drives was to turn the recalibration back on. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message