Date: Tue, 31 Jul 2018 11:04:15 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Robert Clausecker <fuz@fuz.su> Cc: freebsd-fs@freebsd.org Subject: Re: badsect(8) is gone -- what now? Message-ID: <20180731101215.P2056@besplex.bde.org> In-Reply-To: <20180727130743.GB45967@fuz.su> References: <20180727130743.GB45967@fuz.su>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180731101215.P2056>