dump - asleep or suspended ?

J

jaymax

FreeBSD MACH1 10.2-BETA1 FreeBSD 10.2

Beset with hardware instabilities, "NO BOOT DISK" etc. I decided on doing a dump | restore of same prior to disk replacement; cd'ed to /disk_03
nohup dump -C32 -b64 -0uan -h0 -f - / | (cd /disk_03 && restore -ruf -) &
worked fine, 132Gb dumped in about 36 hrs, another 100Gb to go and the system goes down.
Restarted and tried to continue from the termination point by doing an incremental, level 1, dump with -
nohup dump -C32 -b64 -1uan -h0 -f - / | (cd /disk_03 && restore -ruf -) &
process seemed to run for awhile,

Code: 
DUMP: Date of this level 1 dump: Thu Sep 17 17:14:24 2015
...
...
DUMP: 0.42% done, finished in 186:59 at Fri Sep 25 13:02:37 2015
DUMP: 0.50% done, finished in 174:59 at Fri Sep 25 01:07:06 2015
DUMP: 0.56% done, finished in 172:58 at Thu Sep 24 23:11:42 2015

Then apparently stalls, the system is up! but ps -waux | grep -i dump and ps-waux | grep -i restore =>
Code: 
root  806  0.0  0.1  67480  772  0- I  5:14PM  0:03.23 dump -C32 -b64 -1uan -h0 -f - / (dump)
root  808  0.0  1.5  67608 15168  0- S  5:14PM  1:13.12 dump: /dev/ada1p2: pass 4: 11.75% done, finished in 71:43 at Mon Sep 21
root  809  0.0  3.3  67480 33676  0- S  5:14PM  1:16.08 dump -C32 -b64 -1uan -h0 -f - / (dump)
root  810  0.0  3.3  67480 33676  0- S  5:14PM  1:15.39 dump -C32 -b64 -1uan -h0 -f - / (dump)
root  811  0.0  3.3  67480 33676  0- S  5:14PM  1:15.47 dump -C32 -b64 -1uan -h0 -f - / (dump)

and

Code: 
root  807  0.6  1.3 313336 12916  0- D  5:14PM  12:31.41 restore -ruf -

respectively

The ps status unchanged for over 10 hrs, indicating
0- I [Marks a process that is idle (sleeping for longer than about 20 seconds).() ]
0- S [Marks a process that is sleeping for less than about 20 seconds.() ]
0- D [Marks a process in disk (or other short term, uninter-ruptible) wait.() ]

Hard to conceive of a process sleeping > than 20 seconds and at the same time sleeping < 20 seconds!

Is there away to jump start this process?

Thanks!

BTW - another oddity in the dump reports =>
Code: 
finished in 186:59 at Fri Sep 25
yet at the time it was Sep 17th
Sys clock test - Time of posting
# date
Code: 
Fri Sep 18 03:32:43 PDT 2015
would seem to indicate that the system clock is OK?

Thanks again!
 
Bizarre
Some changes evident
ps -wwaux | grep -i dump
Code: 
root  806  0.0  0.1  67480  772  0- I  5:14PM  0:03.23 dump -C32 -b64 -1uan -h0 -f - / (dump)
root  808  0.0  1.6  67608 16868  0- S  5:14PM  1:33.16 dump: /dev/ada1p2: pass 4: 15.35% done, finished in 65:49 at Sun Sep 20 23:00:21 2015 (dump)
root  809  0.0  3.3  67480 33676  0- RL  5:14PM  1:38.15 dump -C32 -b64 -1uan -h0 -f - / (dump)
root  810  0.0  3.3  67480 33676  0- DL  5:14PM  1:37.32 dump -C32 -b64 -1uan -h0 -f - / (dump)
root  811  0.0  3.3  67480 33676  0- DL  5:14PM  1:37.38 dump -C32 -b64 -1uan -h0 -f - / (dump)

And at the same time disk usage as seen from df -k /disk_03 has declined from
an earlier
Code: 
Filesystem                 1024-blocks        Used                  Avail             Capacity                 Mounted on
/dev/gpt/gprootfs                 406246452         142477396       231269340  38%                      /disk_03
to a current
Code: 
Filesystem                  1024-blocks        Used                 Avail              Capacity                Mounted on
/dev/gpt/gprootfs                 406246452         136055000       237691736   36%                     /disk_03

One would have expected the exact opposite as new files would be added?
Bizarre or something not grasped?
 
I never ever have gotten dump/restore working at a reasonable speed, and I was looking for suitable alternatives. I finally ended up writing my own tool for disk cloning, and I submitted it to the ports sysutils/clone, see also clone(1).

Single disk to single disk copying of 232 GB using clone should be done in about 1 to 3 hours (depending on file size and disk speed). If this comes into question:
  1. install sysutils/clone from the ports: # pkg install sysutils/clone
  2. partition the backup drive using gpart(8)
  3. create a new files system on the backup partition: # newfs -jn /dev/adaXpY
  4. turn on ACL on the new disk: #tunefs -a enable /dev/adaXpY
  5. mount the backup partition on a mount point e.g. /mnt: # mount -o noatime /dev/adaXpY /mnt
  6. clone the boot disk as follows: # clone -c rwoff -x .snap:.sujournal / /mnt
The cloned disk can directly be used as the new startup disk.
 
If the target filesystem is empty, using just restore -rf - will be a bit faster.

The only other thing that comes to mind is using dump(8) across an SSH connection. The dump starts, and then the remote password is requested, but the prompt is hidden by the continuing dump(8) output. So it sits there and waits.

It might be worth trying sysutils/cpdup.
 
wblock@ said:
If the target filesystem is empty, using just restore -rf - will be a bit faster.

The only other thing that comes to mind is using dump(8) across an SSH connection. The dump starts, and then the remote password is requested, but the prompt is hidden by the continuing dump(8) output. So it sits there and waits.

It might be worth trying sysutils/cpdup.
Click to expand...
Might be correct, I was working from a remote machine on my LAN through a SSH connection. I'll give sysutils/clone a try first
 
jaymax said:
Might be correct, I was working from a remote machine on my LAN through a SSH connection...
Click to expand...

Submitting lengthy operations via SSH is the typical use case for sysutils/tmux. Even if the connection goes down, the operation would continue. The clone command using tmux(1) would look as follows:
# tmux new "clone -c rwoff -x .snap:.sujournal / /mnt"
 
obsigna said:
Submitting lengthy operations via SSH is the typical use case for sysutils/tmux. Even if the connection goes down, the operation would continue. The clone command using tmux(1) would look as follows:
tmux new "clone -c rwoff -x .snap:.sujournal / /mnt"
Click to expand...

How much more advantageous is that over say
nohup clone -c rwoff -x .snap:.sujournal / /mnt & ?
 
You must log in or register to reply here.
Back
Top