Bug 18319 - dump(8) fails with "cannot reopen disk: interrupted system call"
Summary: dump(8) fails with "cannot reopen disk: interrupted system call"
Status: Closed Unable to Reproduce
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 4.0-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-05-01 07:00 UTC by root
Modified: 2022-12-04 22:20 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description root 2000-04-30 20:50:20 UTC 
>Number:         18319
>Category:       bin
>Synopsis:       "dump" fails with "cannot reopen disk: interrupted system call"
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Apr 30 23:00:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Charlie &
>Release:        FreeBSD 4.0-RELEASE i386
>Organization:
Peter Much, Fichtenstrasse 28, D-65527 Niedernhausen, Germany
>Environment:

IBM ThinkPad 600
IBM 12GB "DARA-212000" Drive
atapci0 identifies: "Intel PIIX4 ATA33 controller"
Filesystem is made just standard out-of-the-box.
Reproduceable with kernel.GENERIC.

>Description:

When doing an incremental backup with dump on the root filesystem (29MB),
or possibly on any small filesystem, and writing to /dev/null or something
able to take the data rather fast, then possibly the dump fails and the
following output is produced:

  DUMP: Date of this level 1 dump: Sun Apr 30 21:12:22 2000
  DUMP: Date of last level 0 dump: Wed Apr 26 22:18:30 2000
  DUMP: Dumping /dev/rad0s3a (/) to /dev/null
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 91 tape blocks on 0.00 tape(s).
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: slave couldn't reopen disk: Interrupted system call
  DUMP: The ENTIRE dump is aborted.

>How-To-Repeat:

This seems timing-critical, because it did already work some times. And now
even after a reboot it always gives this error message. 

>Fix:

At the appropriate place in the sourcecode, if I put a sleep(1) between the
close and the open, the problem is gone away. usleep(1) is also good enough.

>Release-Note:
>Audit-Trail:
>Unformatted:


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Comment 1 root 2000-05-01 07:00:00 UTC 
When doing an incremental backup with dump on the root filesystem (29MB),
or possibly on any small filesystem, and writing to /dev/null or something
able to take the data rather fast, then possibly the dump fails and the
following output is produced:

  DUMP: Date of this level 1 dump: Sun Apr 30 21:12:22 2000
  DUMP: Date of last level 0 dump: Wed Apr 26 22:18:30 2000
  DUMP: Dumping /dev/rad0s3a (/) to /dev/null
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 91 tape blocks on 0.00 tape(s).
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: slave couldn't reopen disk: Interrupted system call
  DUMP: The ENTIRE dump is aborted.

Fix: 

At the appropriate place in the sourcecode, if I put a sleep(1) between the
close and the open, the problem is gone away. usleep(1) is also good enough.
How-To-Repeat: 
This seems timing-critical, because it did already work some times. And now
even after a reboot it always gives this error message.
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:58:41 UTC 
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped