From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 17:50:41 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EB3216A423 for ; Thu, 12 Jan 2006 17:50:41 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C227043D46 for ; Thu, 12 Jan 2006 17:50:40 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id k0CHoYFx021945 for ; Thu, 12 Jan 2006 18:50:35 +0100 (MET) Message-ID: <43C69664.2070505@fer.hr> Date: Thu, 12 Jan 2006 18:48:20 +0100 From: Ivan Voras User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20060112153919.GA21009@dan.emsphone.com> <200601121738.k0CHcbQh063237@gate.bitblocks.com> In-Reply-To: <200601121738.k0CHcbQh063237@gate.bitblocks.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: increasing dd disk to disk transfer rate X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2006 17:50:41 -0000 Bakul Shah wrote: >>In the last episode (Jan 12), Christoph Kukulies said: >>dd if=/dev/ad2 conv=noerror,sync bs=64k | dd of=/dev/ad3 bs=64k > > > So now on the new disk he has files with random blocks of > zeroes and *no* error indication of which files are so > trashed. This is asking for trouble. Silent erros are > worse. > > He ought to do a file level copy, not disk level copy on > unix. That way he knows *which* files are trashed and can do The problem is, FreeBSD panics when it encounters bad sectors in filesystem metadata. I had the same situation ~a month ago and gave up, restoring from old backups. It will also probably panic on corrupted or zeroed metadata, but at least it's on a readable disk...