Date: Thu, 28 Mar 2013 12:45:46 +0000 From: Arthur Chance <freebsd@qeng-ho.org> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-questions@freebsd.org Subject: Re: Copying memstick image to a USB (flash/thumb) drive Message-ID: <51543B7A.4030300@qeng-ho.org> In-Reply-To: <19222.1364466721@server1.tristatelogic.com> References: <19222.1364466721@server1.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/28/13 10:32, Ronald F. Guilmette wrote: > > 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 will attempt to write a short block. E.g. arthur@fileserver[2]> ls -l t.pdf -rw-rw-r-- 1 arthur arthur 233812 Feb 18 12:26 t.pdf arthur@fileserver[2]> dd if=t.pdf of=/dev/null bs=1k 228+1 records in 228+1 records out 233812 bytes transferred in 0.036731 secs (6365521 bytes/sec) Those +1 records are the final short block. > It seems to me that conv=sync is cheap insurance against this > possibility. It's used as an insurance against output devices which have a fixed (or in the case of tape, a minimum) block size. If the short block is not an exact integer multiple of the device block size then the final write will fail. conv=sync and a bs (or obs) that's a strict multiple of block size prevents the problem. That's exactly your use case. > I have always been a belt and suspenders kind of guy. Show me the experienced sysadmin who isn't. Invariably learnt the hard way. :-}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51543B7A.4030300>