Unable to rdump -L -0 a 20G fs?
From: Alexander Langer (alex_at_big.endian.de)
Date: 02/04/04
- Previous message: Vladimir B. Grebenschikov: "Re: HEADS UP: MAJOR changes to the ports system"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 04 Feb 2004 12:30:27 +0100 To: freebsd-current@freebsd.org
Hi!
I have a problem with dump (rdump), as it won't dump -0 my data
filesystem. Higher dumplevels (such as -1 - -9) do work.
It just seems to hang forever:
root@cure ~ # RSH=ssh /sbin/rdump -auL -b 1000 -C 32 -0 -f
defiant-local:/backups/cure/cure-data-level0.dump /data
DUMP: Connection to defiant-local established.
IP_TOS:IPTOS_THROUGHPUT setsockopt: Operation not supported
TCP_NODELAY setsockopt: Operation not supported
DUMP: Date of this level 0 dump: Tue Feb 3 18:31:02 2004
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping snapshot of /dev/da0s1f (/data) to
/backups/cure/cure-data-level0.dump on host defiant-local
DUMP: mapping (Pass I) [regular files]
DUMP: Cache 32 MB, blocksize = 65536
DUMP: mapping (Pass II) [directories]
DUMP: estimated -1529814507 tape blocks.
DUMP: dumping (Pass III) [directories]
This already hangs for 12 hours or so, after I killed the last -0 dump
which already lasted 3 days (!) being in pass 3 (which is rather bad if
you want to do daily backups) The last level 1 dump took only 6.5 hours.
Here's the output of top(1):
PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
88902 root 98 0 39220K 34396K RUN 2 17.0H 92.58% 92.58% rdump
root@cure ~ # ps ax | grep dump
88875 p4 I+ 0:00.40 /sbin/rdump -auL -b 1000 -C 32 -0 -f
defiant-local /data (rdump)
88901 p4 I+ 0:00.03 rdump: /dev/da0s1f: pass 3: directories (rdump)
88902 p4 R+ 1022:04.11 /sbin/rdump -auL -b 1000 -C 32 -0 -f
defiant-local /data (rdump)
88903 p4 I+ 0:00.00 /sbin/rdump -auL -b 1000 -C 32 -0 -f
defiant-local /data (rdump)
88904 p4 I+ 0:00.00 /sbin/rdump -auL -b 1000 -C 32 -0 -f
defiant-local /data (rdump)
root@cure ~ # df -ih /data
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/da0s1f 20G 5.9G 12G 33% 93544 2567830 4% /data
/dev/da0s1f on /data (ufs, local, soft-updates) (UFS2, that is)
root@cure ~ # tunefs -p /data
tunefs: ACLs: (-a) disabled
tunefs: MAC multilabel: (-l) disabled
tunefs: soft updates: (-n) enabled
tunefs: maximum blocks per file in a cylinder group: (-e) 2048
tunefs: average file size: (-f) 16384
tunefs: average number of files in a directory: (-s) 64
tunefs: minimum percentage of free space: (-m) 8%
tunefs: optimization preference: (-o) time
tunefs: volume label: (-L)
FreeBSD cure.... 5.2-RELEASE FreeBSD 5.2-RELEASE #12: Sat Jan 17 11:39:48
CET 2004 alex@cure...:/usr/obj/usr/src/sys/CURE i386
On the remote machine (a 4.9-RELEASE-p1, the dumpfile has filesize 0.
Usually, rdump writing data to the dumpfile from the very beginning,
but:
-rw-r--r-- 1 root wheel 0 Jan 15 12:24 cure-data-level0.dump
(Jan 15 is the day I "touched" the dumpfile).
Here is the level 1 dump.
-rw-r--r-- 1 root wheel 23431680000 Jan 22 06:27 cure-data-level1.dump
This seems to be a full-backup as well, as I've never succeeded in a
level 0 dump before.
Note that I get negative estimated tape blocks (and estimated time) for
level 1 dumps as well, but at least the dumps finish.
Anyone has an explanation? Yes, there is enough diskspace available on
/backups on the remove-machine :-)
Ciao
Alex
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
- Previous message: Vladimir B. Grebenschikov: "Re: HEADS UP: MAJOR changes to the ports system"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
