forcemerge 8171 68216
stop
On 02/01/2024 10:45, ja...@johnstone.net.au wrote:
Hi all,
It seems an instance of `dd` with only an output file doesn't report
the count of records accurately despite bs= being described as
influencing both ibs= and obs=
dd'ing from an unstable remote over ssh today I had it continue from the
last received block between crashes in preparation for a P2V. The remote
had bs=1M set with its in=device and the local instance had bs=1M too
with the destination of= device but upon referring to the receiving
end's stable count of records I noticed it ignored my bs=1M setting.
This were worked around using obs=1M to make the counter show a value I
could reliable skip=/seek= with to resume.
I have an example here:
/$ dd if=/dev/zero bs=1M count=1 | dd bs=1M of=/dev/null
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0010021 s, 1.0 GB/s
*0+16 records in
0+16 records out*
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.000771722 s, 1.4 GB/s/
This is being experienced on Archlinux with kernel '6.6.4' and package
'core/coreutils 9.4-2'
dd's man page for this distribution shows:
/bs=BYTES
read and write up to BYTES bytes at a time (default:
512); overrides ibs and obs/
So I feel it not overriding obs= when invoked with only of= and bs=
arguments could be a bug.
Running a single dd with /if=source of=dest bs=1M/ works as intended.
While in my case this isn't a fatal bug working with virtual block
devices it could be problematic for use cases which require a proper
treatment of block sizes such as tape devices.
Well the behavior is expected and documented:
‘bs=BYTES’
Set both input and output block sizes to BYTES. This makes ‘dd’
read and write BYTES per block, overriding any ‘ibs’ and ‘obs’
settings. In addition, if no data-transforming ‘conv’ operand is
specified, input is copied to the output as soon as it’s read, even
if it is smaller than the block size.
For details please see https://bugs.gnu.org/8171
thanks,
Pádraig.