Date: 07 May 2002 20:08:50 -0500 From: Benjamin Lewis <bhlewis@wossname.net> To: freebsd-current@freebsd.org Subject: Is anyone else having trouble with dump(8) on -current? Message-ID: <1020820130.97599.43.camel@akira.wossname.net>
next in thread | raw e-mail | index | archive | help
Hello, As the subject implies, I've been having some odd troubles with /sbin/dump on a fairly current -CURRENT: FreeBSD akira.wossname.net 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Sat May 4 17:50:36 EST 2002 root@akira.wossname.net:/usr/obj/usr/src-all/current/src/sys/AKIRA i386 I'm running SMP on a dual 1GHz Athlon, Tyan Tiger S2460 based system. dmesg output available upon request. Aside from this single problem, -CURRENT has been remarkably stable on this system. The sources were cvsup-ed just prior to that date and installworld completed soon after: -r-xr-xr-x 2 root wheel 394760 May 4 18:00 /sbin/dump* Now, on to the problem. I use amanda for backups, and since mid-April I've been seeing items like the following in the backup report: /-- akira.woss /var lev 0 FAILED [/sbin/dump returned 3] sendbackup: start [akira.wossname.net:/var level 0] sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/sbin/restore -f... - sendbackup: info end | DUMP: Date of this level 0 dump: Mon Apr 29 00:11:50 2002 | DUMP: Date of last level 0 dump: the epoch | DUMP: Dumping /dev/da0s3e (/var) to standard output | DUMP: mapping (Pass I) [regular files] | DUMP: mapping (Pass II) [directories] | DUMP: estimated 36490 tape blocks. | DUMP: dumping (Pass III) [directories] | DUMP: slave couldn't reopen disk: Interrupted system call | DUMP: The ENTIRE dump is aborted. sendbackup: error [/sbin/dump returned 3] \-------- The actual failed partition varies; no single filesystem consistently fails. I can occasionally reproduce the error by running a dump by hand. More often, I cannot. The filesystems that fail are all on a single disk (da0): da0: <FUJITSU MAF3364L SUN36G 1213> Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) No filesystems on the other SCSI disk ever fail. The Fujitsu is a replacement for a disk that recently went bad and the filesystems were restored from tape. The dump problems happened soon, but not immediately, after the new disk was brought on-line. After a few successful backup runs I decided to update the system from the early March sources it had been running, and that's when this problem began. I've rebuilt the system from current-at-the-time sources several times since, whenever the mailing lists suggested it was safe-ish. I was just playing around, trying to duplicate the problem and the following happened, 2 failures and then a success: $ dump 0af /dev/null / DUMP: Date of this level 0 dump: Tue May 7 19:59:49 2002 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/da0s1a (/) to /dev/null DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 693225 tape blocks. DUMP: slave couldn't reopen disk: Interrupted system call DUMP: The ENTIRE dump is aborted. $ dump 0af /dev/null / DUMP: Date of this level 0 dump: Tue May 7 19:59:53 2002 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/da0s1a (/) to /dev/null DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 693225 tape blocks. DUMP: slave couldn't reopen disk: Interrupted system call DUMP: The ENTIRE dump is aborted. $ dump 0af /dev/null / DUMP: Date of this level 0 dump: Tue May 7 19:59:54 2002 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/da0s1a (/) to /dev/null DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 693225 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: DUMP: 711739 tape blocks on 1 volume DUMP: finished in 176 seconds, throughput 4043 KBytes/sec DUMP: Closing /dev/null DUMP: DUMP IS DONE If anyone has some insight into this, I'd very much appreciate the help. Thanks, -Ben To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1020820130.97599.43.camel>