From owner-freebsd-questions@FreeBSD.ORG Thu Mar 28 10:32:06 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 16089971 for ; Thu, 28 Mar 2013 10:32:06 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id EC6A7CCA for ; Thu, 28 Mar 2013 10:32:04 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 07BB43AEB5; Thu, 28 Mar 2013 03:32:01 -0700 (PDT) From: "Ronald F. Guilmette" To: Quartz Subject: Re: Copying memstick image to a USB (flash/thumb) drive In-Reply-To: <5153FEFF.4090305@sneakertech.com> Date: Thu, 28 Mar 2013 03:32:01 -0700 Message-ID: <19222.1364466721@server1.tristatelogic.com> Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 10:32:06 -0000 In message <5153FEFF.4090305@sneakertech.com>, you wrote: > >> I have filed the following PR: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=177431 > >Er, don't take my word for law: I didn't. I won't. >I have *no* idea if 1M is a good idea Any size which is an exact multiple of the physical block size for the target device should provide performance which is as good as it gets. I googled around and read various comments. Some of these kinds of devices have a physical block size of 64KiB. Some have 128KiB. Some have 256KiB. Some have 1MiB. For all of these devices, seting blocksize to 1MiB will provide optimal performance with at worst only a _relatively_ tiny waste of space. >As for the conv=sync option, I'm not convinced it's necessary either >way. Neither am I, but I would rather have it there, than not and take chances. It won't hurt anything, and it appears that it _may_ perhaps help. >I don't think modern systems really care what the end is padded with That wasn't my concern. My concern is that I personally do not know what the officially defined semantics are in cases where dd is asked to copy data in a specific input block size _and_ the actual data available from the input device doesn't perfectly fill up that last block. It is possible, I would guess, that dd may notice the EOF occuring before it has filled up an entire input buffer, and then just quit at that point, _without_ writing the partial last block to the output device. It seems to me that conv=sync is cheap insurance against this possibility. I have always been a belt and suspenders kind of guy. Regards, rfg