Date: Sat, 28 Feb 2004 07:53:08 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Andre Oppermann <andre@freebsd.org> Cc: FreeBSD current users <current@freebsd.org> Subject: Re: would this be a useful utility? Message-ID: <20040227205308.GA75246@server.vk2pj.dyndns.org> In-Reply-To: <403E53C6.40100@freebsd.org> References: <Pine.BSF.4.21.0402261136060.6679-100000@InterJet.elischer.org> <403E53C6.40100@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 26, 2004 at 09:15:02PM +0100, Andre Oppermann wrote: >Oh yes. I just got a 1GB compact flash on which appearently one >sector is defect. I know the file it is in but can't figure out >how to avoid it. If you know which block in the file is defective, you can use truncate(1) to delete blocks after the defective one. You should be able to use fsdb(8) to locate the physical block number. If it's a small file, just rename it to something like '.bad_blocks', mark it nodump (amd maybe schg) and remember not to read or delete it. Unfortunately, there's no simple way to free the blocks between the beginning of the file and the bad block. The easiest way would be to create a single dummy file that occupied all the remaining free space, delete the file with the defective block and then create N 1-block files (1 for every block in the file). One of these files will contain the defective block and can be renamed as above, then the remaining files can be deleted. You probably want to do this with softupdates turned off (so you don't have to wait for the delayed free space release). Note that this includes a fair bit of FS churn so it may be undesirable on a flash device with limited write cycles. Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040227205308.GA75246>