Date: Sat, 20 Nov 2010 16:16:55 +0100 From: Matthias Apitz <guru@unixarea.de> To: Alexander Motin <mav@freebsd.org> Cc: freebsd-usb@freebsd.org Subject: Re: copying /dev/da0 with dd(1) to file: output differs Message-ID: <20101120151655.GA4010@current.Sisis.de> In-Reply-To: <4CE6C73A.4070208@FreeBSD.org> References: <201011191916.53655.hselasky@c2i.net> <mailpost.1290191957.493865.17097.mailing.freebsd.usb@FreeBSD.cs.nctu.edu.tw> <4CE6C73A.4070208@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 196971833 134 34 196971845 134 34 196971849 134 34 196971875 134 34 196971901 134 34 196971945 134 34 196971955 134 34 196972210 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: $ sed 's/ */ /g' diff | cut -d' ' -f2,3 | sort -u 0 10 0 104 0 110 0 200 0 204 0 214 0 220 0 234 0 260 0 4 10 0 100 0 110 0 134 0 134 14 134 34 134 4 14 0 200 260 204 234 204 4 214 234 220 260 304 204 34 0 4 0 4 104 4 234 44 0 44 4 (the numbers are in octal). What does this mean? Does not look like errors, in case of random error it whould be more caotic, or? matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e <guru@unixarea.de> - w http://www.unixarea.de/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101120151655.GA4010>