hat processing each member of a multimember file separately).
$ time lziprecover -v -Fc2% archive.tar.lz
archive.tar.lz.fec: 300_754_928 bytes, 300_482_560 fec bytes, 655 blocks
real 450m44,092s
user 171m33,329s
sys 27m56,155s
These times mean that lziprecover spent most of the time waiting for the
disk. Fec file creation is multithreaded. On a 4-processor machine with
enough RAM the command above should have completed in 45 minutes or so.
I rerun this command during the night, this time I shut down the backup
server that's running (just a couple of container and VM are backed up,
it takes usually less than 10 min) and I get this slightly better outcome
$ time lziprecover -v -Fc2% archive.tar.lz
archive.tar.lz.fec: 300_754_928 bytes, 300_482_560 fec bytes, 655 blocks
real 407m19,994s
user 171m18,431s
sys 27m58,918s
I tried to find what cause all this wait, htop show lziprecover
continuously reading at full speed, with the disk I/O reaching 95-100%
during all that time and vmstat report a very high disk reading usage
but very low swap activity.
Regards.
