In message <5153feff.4090...@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 _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"