bin/121684: : dump(8) frequently hangs

[Mike Tancsa]

At 05:38 PM 9/1/2008, Jeremy Chadwick wrote:

>Can someone explain what "dump frequently hangs" actually means?
>
>Does it lock up the entire machine indefinitely (and if so, how long did
>you wait for it to (hopefully) recover)?


As in the process hanging.  For me, it was fixed quite some time ago.


[zoo]# ps -auxlww | grep dump
root     32093  0.0  3.8 39972 38036  ??  D    Fri11PM   0:00.43 
/sbin/dump -C24      0     1   0  20  0 pause
root     73970  0.0  2.7 28708 26688  ??  D    Thu11PM   0:00.14 
/sbin/dump -C24      0     1   1  20  0 pause
root     80852  0.0  3.8 39972 38000  ??  D    11:30PM   0:18.43 
/sbin/dump -C24      0     1   0  20  0 pause
root     98637  0.0  0.1  3308  1040  pd  RL+   8:20AM   0:00.00 grep 
dump            0 72305   0  96  0 -
[zoo]# kill -9 80852
[zoo]# kill -9 80852
[zoo]# kill -9 80852
[zoo]# ps -auxlww | grep dump
root     32093  0.0  3.8 39972 38036  ??  D    Fri11PM   0:00.43 
/sbin/dump -C24      0     1   0  20  0 pause
root     73970  0.0  2.7 28708 26688  ??  D    Thu11PM   0:00.14 
/sbin/dump -C24      0     1   1  20  0 pause
root     80852  0.0  3.8 39972 38000  ??  D    11:30PM   0:18.43 
/sbin/dump -C24      0     1   0  20  0 pause
root     98639  0.0  0.1  3308  1040  pd  R+    8:20AM   0:00.00 grep 
dump            0 72305   0  96  0 -
[zoo]#




>[1]: rsync is great for backups, and very fast, but there's the issue of
>modifying atimes.  I committed a patch to ports/net/rsync which adds an
>--atimes flag, except its behaviour is not what you'd expect: the file
>which was copied, at the destination, has the correct atime (of the
>source), but the source itself ends up getting its atime modified, so
>you're essentially destroying the atime data on the source.

One of the reasons I dont use it for backups.  Also its a pain with 
things like /dev and other special files.

         ---Mike