Problem with dump stalling
koitsu at FreeBSD.org
Wed Oct 8 01:54:14 PDT 2008
On Wed, Oct 08, 2008 at 10:29:00AM +0200, David Peall wrote:
> If I have the wrong list please feel free to redirect me.
> I'm running 7.0-RELEASE-p4 and trying to backup to an external USB
> I'm using the following command
> dump -a0Lf /backup/diskimages/root /dev/mfid0s1a
> Where df:
> Filesystem 1K-blocks Used Avail Capacity Mounted on
> /dev/mfid0s1a 507630 208436 258584 45% /
> /dev/da1s1d 709513458 9853800 642898582 2% /backup
> The following processes start
> 75399 p0 I+ 0:00.04 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump)
> 75402 p0 S+ 0:00.71 dump: /dev/mfid0s1a: pass 4: 77.05% done, finished in 0:00 at Wed Oct 8 08:25:06 2008 (dump)
> 75403 p0 S+ 0:00.85 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump)
> 75404 p0 S+ 0:00.96 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump)
> 75405 p0 S+ 0:00.86 dump -a0Lf /backup/diskimages/root /dev/mfid0s1a (dump)
> But it just stops at a random percentage, the system continues to run
> and the processes are killable?
> Perhaps I'm using dump incorrectly if anyone could help would be greatly
This is a known problem with dump on UFS2 filesystems. See
There is no fix, AFAIK.
My recommendation is to use something else. I'm particularly fond of
rsnapshot, but be aware that rsync will cause file atimes to be lost
(on the source) when copying; this can impact classic UNIX mail
spools (mbox), where people use clients like mutt/pine which utilise
atimes to determine if there's new mail or not.
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
More information about the freebsd-stable