Re: [Dump-users] Unable to handle removed files via incremental dumps

[Stelian P. <st...@po...>]

On Fri, Feb 06, 2004 at 03:54:51PM +0200, Delian Krustev wrote:

> I've updated dump/e2fsprogs to the latest versions and performed the tests.

Are you perfectly sure you updated dump ? You use 
/usr/sbin/dump below, but my RPMS try to install
/sbin/dump... Make sure you don't have several versions of dump
on your disk.

> 
> This went fine:
> time /usr/sbin/dump -0uf - /dev/vg1/snaphome |gzip |split -b 1024m
> 
> This also:
> time cat xaa xab |gunzip|restore -rdvuf - >/home/out.log 2>/home/err.log
> 
> However this has failed:
> time /usr/sbin/dump -1uf - /dev/vg1/snaphome | restore -rdvuf - >/home/out1.log 2>/home/err1.log

Hmm, really strange, the direct pipe should be the same as when
going through cat/gzip. It alsa seems to crash after the full dump
and restore has finished (

I cannot see what is causing this. Try running the same command
but with dump under strace -ff (strace -ff /usr/sbin/dump -1u...). 
Does this show something about the crash ?

Second thought: compile dump  with debug enabled and run it through
gdb, then when it crashes use commands like "bt" to see where
it happened.

> real    54m42.457s
> user    0m25.730s
> sys     0m36.370s

[...]

> One more question. What are these times that dump reports ?

54 minutes of real execution (clock time), 25 effective execution
in algorithms, 36 seconrds in doing syscalls. Most of the time
(53 minutes) was spend in waiting for the disk to be ready for read/write.

See man 1 time and man 2 times for details.

Stelian.
-- 
Stelian Pop <st...@po...>