*BSD News Article 12869


Return to BSD News archive

Newsgroups: comp.os.386bsd.questions
Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!ipso!runxtsa!bde
From: bde@runx.oz.au (Bruce Evans)
Subject: Re: badsect not working.
Message-ID: <1993Mar12.162009.16095@runx.oz.au>
Organization: RUNX Un*x Timeshare.  Sydney, Australia.
References: <1nlk33$is@tricky.wft.stack.urc.tue.nl> <1993Mar11.102133.587@cnplss5.cnps.philips.nl>
Date: Fri, 12 Mar 93 16:20:09 GMT
Lines: 28

In article <1993Mar11.102133.587@cnplss5.cnps.philips.nl> rooij@mozart.cft.philips.nl (Guido van Rooij) writes:
>jim@wft.stack.urc.tue.nl (Jim Rump,,040-518599,040-518599) writes:
>...
>>I am trying to use a IDE-disk with badsectors. The badsect command does not
>>work for me. When I use badsect as described in the manualpage, I get
>>a "Device busy". What could I be doing wrong here?.
>
>An IDE drive remaps its bad sectors transparently to the outside world, 
>so you should never use bad144 with those disks.

Jim said his IDE has bad sectors, and he's trying to use badsect, not
bad144.  I think it's OK to use bad144 on an IDE if necessary.  I'd
like to run badsect as well as bad144 to hide all the sectors on all
tracks with bad sectors in files that aren't accessed very often.

The problem with badsect seems to be the following creative use of mknod():

	if (mknod(*argv, IFMT|0600, dbtofsb(fs, number)) < 0) {
		/* fail */
	}

mknod() no longer works for arbitrary modes.  It only works for char and
block special modes.  The third arg to mknod() is normally the device.
The above mknod() must have "worked" because the device number was
stored in the same place in the inode as the first block number.  The
actual allocation of the block is done by fsck.
-- 
Bruce Evans  bde%runx.oz.au@ips.oz.au