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.
