From owner-freebsd-usb@FreeBSD.ORG Sun Nov 21 00:24:35 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 355A9106566C; Sun, 21 Nov 2010 00:24:35 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 140AA8FC15; Sun, 21 Nov 2010 00:24:35 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id oAL0OWgX042171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Nov 2010 16:24:34 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id oAL0OW8A042170; Sat, 20 Nov 2010 16:24:32 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA05385; Sat, 20 Nov 10 16:19:49 PST Date: Sat, 20 Nov 2010 16:19:48 -0800 From: perryh@pluto.rain.com To: guru@unixarea.de, mav@freebsd.org Message-Id: <4ce865a4.aMSvcjRoHgImeAYF%perryh@pluto.rain.com> References: <201011191916.53655.hselasky@c2i.net> <4CE6C73A.4070208@FreeBSD.org> <20101120151655.GA4010@current.Sisis.de> In-Reply-To: <20101120151655.GA4010@current.Sisis.de> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org Subject: Re: copying /dev/da0 with dd(1) to file: output differs X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Nov 2010 00:24:35 -0000 Matthias Apitz wrote: > El d?a Friday, November 19, 2010 a las 08:51:38PM +0200, > Alexander Motin escribi?: > > > Could it be that unwritten/unformatted blocks are read as > > > random data from that USB key? Should I overwrite the full > > > USB key from /dev/zero? > > > > It is allowed behavior for SATA SSDs with TRIM command support. > > Deleted blocks can be not guarantied to return any predictable > > or even repeatable value. May be this logic could be extended to > > USB devices. > > A cmp(1) with -l gives a file like this: > > $ head -10 diff > 196971771 134 34 > 196971797 134 34 ... > of 2385059 lines, i.e. of 2385059 bytes which differ in the 3.8 > GByte copy; there are only a few patterns of diffs which are > repeating: ... > What does this mean? Does not look like errors, in case of random > error it whould be more caotic, or? Good question. To help sort out whether it matters, what happens if you read the stick using dump(8) instead of dd (or mount it read-only and read it with tar)? Either of those methods will read only the parts that are in use.