All, I am a heavy user of dd and think I know it well, but we had some unexpected behavior out of dd recently. At least it was unexpected by us. In its simplest reproducible form we did something like: md5sum big_file cat big_file | dd bs=32k conv=sync,noerror | md5sum big_file was a multiple of 32k long, so we expected the results to be identical. They were not. It appears that if dd consumes data faster than cat can produce it, then dd will get partial block reads. ie. the 32k reads will get less than 32k out of the pipe. When that happens, I suspect dd flags it as an error read and with the above 'conv=sync,noerror' arg, dd fills the 32k block with zeros. Thus the data passed into md5 has been corrupted from the original and we get a different md5sum. We found that totally dropping the 'conv=sync,noerror' arg eliminates the problem, although I'm not positive how that works. dd still reports a lot of read errors, but the md5 is right. Not very comforting to see it report hundreds of read errors just reading a couple GB of data. Also, changing the block size to 4k, fixes it. I assume because cat is working in blocks of 4k or a multiple there of. No read errors reported at all this way. Anyway, I don't know if the above is by design, or if we have come across a bug. If a bug, is it in dd? the kernel? FYI: I know conv=sync,noerror is not needed in the above. We tend to use it just in case something goes wrong. In this case, it made things go wrong! Thanks Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org