GNU bug report logs - #38186
dd doesn't copy whole file when specifying units with bs

Previous Next

Package: guix;

Reported by: Jack Hill <jackhill <at> jackhill.us>

Date: Tue, 12 Nov 2019 20:48:01 UTC

Severity: normal

Done: Jack Hill <jackhill <at> jackhill.us>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38186 in the body.
You can then email your comments to 38186 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#38186; Package guix. (Tue, 12 Nov 2019 20:48:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jack Hill <jackhill <at> jackhill.us>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Tue, 12 Nov 2019 20:48:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jack Hill <jackhill <at> jackhill.us>
To: bug-guix <at> gnu.org
Subject: dd doesn't copy whole file when specifying units with bs
Date: Tue, 12 Nov 2019 15:47:19 -0500 (EST)
Hi Guix,

It seems that my version of dd from coreutils-8.31 does not seem to work 
correctly when using units with the bs option (e.g. bs=1M). In the 
terminal session below, I first use bs=1M. The output looks okay: dd 
appears to have copied the whole 2.3GiB file, but it has done so 
impossibly quickly. It turns out that went so quickly because the whole 
file has not been copied. If instead of using the units modifier, I 
specify the same number of bytes directly, everything seems to work as 
expected (notice the slower speed).

I have not determined whether this problem is specific to Guix.

```
$ sudo dd if=image.iso of=/dev/sda bs=1M
2349+1 records in
2349+1 records out
2463842304 bytes (2.5 GB, 2.3 GiB) copied, 1.0693 s, 2.3 GB/s
$ sudo dd if=image.iso of=/dev/sda bs=1048576
2349+1 records in
2349+1 records out
2463842304 bytes (2.5 GB, 2.3 GiB) copied, 3.03265 s, 812 MB/s
$ ls -l /run/current-system/profile/bin/dd
lrwxrwxrwx 18 root root 65 Dec 31  1969 /run/current-system/profile/bin/dd 
-> /gnu/store/9kzrrccpzl6i1sfwb0drb00gi2gwk0x0-coreutils-8.31/bin/dd
$ guix describe
Generation 42	Oct 28 2019 11:51:58	(current)
  guix 8c8d607
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 8c8d60752e1ad73d5bd87d8497b357f8a8a389ab
```

Best,
Jack




Information forwarded to bug-guix <at> gnu.org:
bug#38186; Package guix. (Tue, 12 Nov 2019 21:46:01 GMT) Full text and rfc822 format available.

Message #8 received at 38186 <at> debbugs.gnu.org (full text, mbox):

From: clement <at> lassieur.org (Clément Lassieur)
To: Jack Hill <jackhill <at> jackhill.us>
Cc: 38186 <at> debbugs.gnu.org
Subject: Re: bug#38186: dd doesn't copy whole file when specifying units with
 bs
Date: Tue, 12 Nov 2019 22:45:18 +0100
Hi Jack,

> It seems that my version of dd from coreutils-8.31 does not seem to work
> correctly when using units with the bs option (e.g. bs=1M). In the terminal
> session below, I first use bs=1M. The output looks okay: dd appears to have
> copied the whole 2.3GiB file, but it has done so impossibly quickly. It turns
> out that went so quickly because the whole file has not been copied. If
> instead of using the units modifier, I specify the same number of bytes
> directly, everything seems to work as expected (notice the slower speed).

Does this[1] help?

[1]: https://superuser.com/questions/730801/dd-immidiately-completes-but-actually-needs-sync




Reply sent to Jack Hill <jackhill <at> jackhill.us>:
You have taken responsibility. (Wed, 13 Nov 2019 16:18:05 GMT) Full text and rfc822 format available.

Notification sent to Jack Hill <jackhill <at> jackhill.us>:
bug acknowledged by developer. (Wed, 13 Nov 2019 16:18:06 GMT) Full text and rfc822 format available.

Message #13 received at 38186-done <at> debbugs.gnu.org (full text, mbox):

From: Jack Hill <jackhill <at> jackhill.us>
To: Clément Lassieur <clement <at> lassieur.org>
Cc: 38186-done <at> debbugs.gnu.org
Subject: Re: bug#38186: dd doesn't copy whole file when specifying units with
 bs
Date: Wed, 13 Nov 2019 11:17:43 -0500 (EST)
[Message part 1 (text/plain, inline)]
On Tue, 12 Nov 2019, Clément Lassieur wrote:

> Does this[1] help?
>
> [1]: https://superuser.com/questions/730801/dd-immidiately-completes-but-actually-needs-sync

Indeed it does. I guess I just got lucky with the second invocation that 
data got written out. Thanks very much for the pointer, and sorry for the 
extra noise.

Since I no longer believe this to be a bug, I'm closing it.

Best,
Jack

Information forwarded to bug-guix <at> gnu.org:
bug#38186; Package guix. (Wed, 13 Nov 2019 17:01:02 GMT) Full text and rfc822 format available.

Message #16 received at 38186-done <at> debbugs.gnu.org (full text, mbox):

From: Clément Lassieur <clement <at> lassieur.org>
To: Jack Hill <jackhill <at> jackhill.us>
Cc: 38186-done <at> debbugs.gnu.org
Subject: Re: bug#38186: dd doesn't copy whole file when specifying units with
 bs
Date: Wed, 13 Nov 2019 18:00:41 +0100
Jack Hill <jackhill <at> jackhill.us> writes:

> On Tue, 12 Nov 2019, Clément Lassieur wrote:
>
>> Does this[1] help?
>>
>> [1]: https://superuser.com/questions/730801/dd-immidiately-completes-but-actually-needs-sync
>
> Indeed it does. I guess I just got lucky with the second invocation that data
> got written out. Thanks very much for the pointer, and sorry for the extra
> noise.
>
> Since I no longer believe this to be a bug, I'm closing it.

You're welcome :)
Clément




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 12 Dec 2019 12:24:12 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 136 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.