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

[Jim Meyering]

Pádraig Brady wrote:

> 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".

Truncating a large file can cause a surprising delay, due to the amount of
metadata manipulation that must be performed on some file system types.