Re: AW: dd killed with USR1 right after ftruncate()

[Pádraig Brady]

Jim Meyering wrote:
> Voelker, Bernhard wrote:
>> Pádraig wrote:
>>
>>> What is your exact dd command please, and destination file system.
>> I was running KNOPPIX 5.3.1; the source was a harddisk partition, and
>> the target was a file in an ext2 filesystem on a harddisk in an USB device
>> mounted on /media/sdb2/:
>>
>>      $ dd if=/dev/sda5 of=/media/sdb2/backups/sda5 bs=1G
>>
>>> I'm a bit confused as ftruncate is not called unless you specify a
>>> non zero seek= but that seems a bit weird from your described usage.
>> hmm, so maybe it has not actually been the truncate() which took
>> so long but the fd_reopen() using O_TRUNC.
> 
> Sounds like a good reason to defer SIGUSR1 from post-getopt/arg-verify
> until when the copy-timer starts.

Yep I think so. Moving just the install_signal_handlers() to the top,
then when the copy starts you'll get:

0+0 records in
0+0 records out
0 bytes (0 B) copied, 3.6457e-05 s, 0.0 kB/s

cheers,
Pádraig.

p.s. I'm still unsure as to why open(O_TRUNC) takes "a while".
Perhaps there is a trunc=paranoid mount option I'm unaware of
that actually writes zeros when truncating a file.