From owner-freebsd-fs@freebsd.org Tue Jul 31 01:04:39 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B36511067145 for ; Tue, 31 Jul 2018 01:04:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 5506070E6E for ; Tue, 31 Jul 2018 01:04:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id D011D10937D; Tue, 31 Jul 2018 11:04:15 +1000 (AEST) Date: Tue, 31 Jul 2018 11:04:15 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Robert Clausecker cc: freebsd-fs@freebsd.org Subject: Re: badsect(8) is gone -- what now? In-Reply-To: <20180727130743.GB45967@fuz.su> Message-ID: <20180731101215.P2056@besplex.bde.org> References: <20180727130743.GB45967@fuz.su> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=EseilWUA c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=V3VVewBL9YRdEGTVxaoA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2018 01:04:39 -0000 On Fri, 27 Jul 2018, Robert Clausecker wrote: > I recently tried to use badsect(8) to salvage a slightly broken disk > with some janky sectors which the drive doesn't remap but still likes to > complain about, just to find out that kernel support for badsect(8) is > no longer available in FreeBSD 11.2. This is an annoying situation as I > have no way to stop these sectors from being used otherwise. > > Is there any way the kernel interface for badsect(8) or a utilitiy > fulfilling a similar purpose is going to come back? I understand that > kernel support was removed due to possible misuse of mknod(S_IFMT) > leading to crashes [1], but there really ought to be some way to mark a > sector as bad if the disk doesn't want to do it for you. badsect(8) was removed when I pointed out that removing the kernel support for it was a bug. The bug is larger now. You can hide the bad sectors manually no worse than badsect(8)+fsck did after first finding them and allocating them in files. This is much harder to do systematically than with badsect, but if you just wait for bad sectors to develop and chmod files to 000 and move them out of the way (and don't try to recover good sectors in then), the result is not much different than with badsect. Root can still read these files, so there tree walks might stumble over them. If a bad sector develops in metdata, then this doesn't work so well, but neither did badsect. Most metadata is for inodes and bad sectors for inodes cannot be handled. In practice, the slowest part might be finding the bad sectors. The whole disk must be read, and i/o on the bad sectors is especially slow due to retries. I once remapped bad sectors on mere 30GB and 100GB disks with a few thousand bad sectors, by reading and writing all sectors and hoping that the disk reallocated the bad ones (it mostly did at first on the 30GB disk, and mostly failed on the 80GB disk, but the 30GB eventually became unusable while the 80GB disk still works perfectly except for 1 region of ~20GB in the middle). Bad sectors must be read and written 1 sector a time to locate them, and this is already much slower than reading many at a time. I used dd to locate problem areas on the disks, and a simple utility do 1-sector reads and writes in these areas. The utility prints sector numbers in a form more useful than kernel or dd error messages. Bruce