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.
