Bug 30869

Summary:	dump(8) does not dump all files of a filesystem
Product:	Base System	Reporter:	Heinrich Rebehn <rebehn>
Component:	bin	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	4.3-RELEASE
Hardware:	Any
OS:	Any

Description Heinrich Rebehn 2001-09-27 14:30:00 UTC

dump does not dump all files of a fliesystem when b=1000 is used. No problem if 'b' is not specified. I use b=1000 because of significant speed improvement w/ DLT tape.

How-To-Repeat: dump any large (~3G) filesystem to tape or file:

# dump 0cafb /dev/nrsa0 1000 /export/solaris
  DUMP: Date of this level 0 dump: Thu Sep 27 11:14:06 2001
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/twed0s1d (/export/solaris) to /dev/nrsa0
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 3416548 tape blocks.
  DUMP: dumping (Pass III) [directories]
  DUMP: 0.03% done, finished in 0:56
  DUMP: dumping (Pass IV) [regular files]
  DUMP: 38.99% done, finished in 0:07
  DUMP: 75.28% done, finished in 0:03
  DUMP: DUMP: 3407516 tape blocks on 1 volume
  DUMP: finished in 783 seconds, throughput 4351 KBytes/sec
  DUMP: Closing /dev/nrsa0
  DUMP: DUMP IS DONE

If the problem occurs you get an error like the following when using restore:

# restore xfb /dev/nrsa0 1000
bad name to addentry ./openwin/lib/X11/locale/C/help

restore -i shows that the directory 'locale' is empty!

Comment 1 Giorgos Keramidas freebsd_committer

2002-09-27 03:08:52 UTC

: dump does not dump all files of a fliesystem
: when b=1000 is used. No problem if 'b' is not
: specified. I use b=1000 because of significant
: speed improvement w/ DLT tape.

Hello Heinrich,

Does this problem appear with dump/restore
of newer FreeBSD releases too?

Comment 2 Heinrich Rebehn 2002-09-27 11:35:41 UTC

Giorgos Keramidas wrote:
> : dump does not dump all files of a fliesystem
> : when b=1000 is used. No problem if 'b' is not
> : specified. I use b=1000 because of significant
> : speed improvement w/ DLT tape.
> 
> Hello Heinrich,
> 
> Does this problem appear with dump/restore
> of newer FreeBSD releases too?
> 
> 

Hi Giorgos,

thanks for inquiring about this bug.
The situation is as follows:

- I don't use b=1000 anymore but use 64 instead, which gives best performance
- A small test with b=1000 yielded :
root@antsrv1 [/export/stuff/backup/test] # dump 0afb usr.dmp 1000 /usr
   DUMP: Date of this level 0 dump: Fri Sep 27 09:18:00 2002
   DUMP: Date of last level 0 dump: the epoch
   DUMP: Dumping /dev/ad0s2f (/usr) to usr.dmp
   DUMP: mapping (Pass I) [regular files]
   DUMP: mapping (Pass II) [directories]
   DUMP: estimated 1086729 tape blocks.
   DUMP: dumping (Pass III) [directories]
   DUMP: 0.09% done, finished in 0:18
   DUMP: dumping (Pass IV) [regular files]
   DUMP: 65.43% done, finished in 0:02
   DUMP: master/slave protocol botched.
   DUMP: The ENTIRE dump is aborted.

- A test with b=64 yielded:
root@antsrv1 [/export/stuff/backup/test] # dump 0afb usr.dmp 64 /usr
   DUMP: Date of this level 0 dump: Fri Sep 27 10:14:02 2002
   DUMP: Date of last level 0 dump: the epoch
   DUMP: Dumping /dev/ad0s2f (/usr) to usr.dmp
   DUMP: mapping (Pass I) [regular files]
   DUMP: mapping (Pass II) [directories]
   DUMP: estimated 1086729 tape blocks.
   DUMP: dumping (Pass III) [directories]
   DUMP: dumping (Pass IV) [regular files]
   DUMP: 56.93% done, finished in 0:03
   DUMP: DUMP: 1179590 tape blocks on 1 volume
   DUMP: finished in 573 seconds, throughput 2058 KBytes/sec
   DUMP: Closing usr.dmp
   DUMP: DUMP IS DONE
root@antsrv1 [/export/stuff/backup/test] # ls
usr.dmp
root@antsrv1 [/export/stuff/backup/test] # restore rf usr.dmp
cannot find directory inode 462338
abort? [yn] n

However a diff -r "/usr ." was ok (Only "no such file or dir" errors because of 
dead symlinks)

root@antsrv1 [/export/stuff/backup/test] # uname -a
FreeBSD antsrv1.ant.uni-bremen.de 4.6.2-RELEASE FreeBSD 4.6.2-RELEASE #0: Wed 
Aug 14 21:23:26 GMT 2002 
murray@builder.freebsdmall.com:/usr/src/sys/compile/GENERIC  i386

Conclusion: I can live with dump as is, but it still seems to have some issues. 
I leave it up to you to decide if the bug should be closed.

Kind regards,


Heinrich Rebehn

University of Bremen
Physics / Electrical and Electronics Engineering
- Department of Telecommunications -

E-mail: mailto:rebehn@ant.uni-bremen.de
Phone : +49/421/218-4664
Fax   :            -3341

Comment 3 Doug Barton freebsd_committer

2003-01-23 10:28:04 UTC

State Changed
From-To: open->feedback


Does this still happen on a more recent system?

Comment 4 Doug Barton freebsd_committer

2003-02-17 19:21:31 UTC

State Changed
From-To: feedback->open


Originator states that the problem still exists with 4.6.2.

Comment 5 Harrison Grundy 2007-03-22 04:20:44 UTC

Does this occur on FreeBSD 5.x or 6.x?

Comment 6 Remko Lodder freebsd_committer

2007-03-29 06:51:34 UTC

State Changed
From-To: open->closed

feedback timeout