NetBSD Problem Report #24181

Received: (qmail 3958 invoked by uid 605); 21 Jan 2004 08:18:17 -0000
Message-Id: <200401210818.i0L8IDxv024357@ophidian.must-have-coffee.gen.nz>
Date: Wed, 21 Jan 2004 21:18:13 +1300 (NZDT)
From: Lloyd Parkes <lloyd@must-have-coffee.gen.nz>
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: lloyd@must-have-coffee.gen.nz
To: gnats-bugs@gnats.netbsd.org
Subject: files created by dump(8) are too big
X-Send-Pr-Version: 3.95

>Number:         24181
>Category:       bin
>Synopsis:       files created by dump(8) are too big
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 21 08:19:00 +0000 2004
>Closed-Date:    
>Last-Modified:  
>Originator:     Lloyd Parkes
>Release:        NetBSD 1.6.1_STABLE
>Organization:
Must Have Coffee
>Environment:
System: NetBSD ophidian.must-have-coffee.gen.nz 1.6.1_STABLE NetBSD 1.6.1_STABLE (Workstation) #1: Mon Jun 2 15:43:10 NZST 2003 lloyd@ophidian.must-have-coffee.gen.nz:/data/src/sys/arch/i386/compile/Workstation i386
Architecture: i386
Machine: i386
>Description:

I have my machine set up to do a level 9 dump of /data every day. Most
of /data has the nodump flag set on it.

bash-2.05b# ls -lo /data/
total 116
drwxr-xr-x   6 lloyd  wheel  -        512 Jun 29  2002 cvs
drwxr-xr-x   8 lloyd  wheel  nodump   512 Jun  1  2003 cvs-src
drwxr-xr-x  27 lloyd  wheel  nodump 18944 Jan 21 03:00 distfiles
drwxr-xr-x   8 100    users  -        512 Mar 28  2003 htdocs
drwx-----T   2 lloyd  wheel  nodump 91136 Jun  1  2003 lost+found
drwxr-xr-x   5 lloyd  wheel  nodump  1024 Dec 11 20:10 mldonkey
drwxr-xr-x  18 lloyd  wheel  nodump   512 Nov 26 19:43 obj
drwxr-xr-x  48 lloyd  wheel  nodump  1024 Nov 26 18:15 pkgsrc
drwxr-xr-x  21 lloyd  wheel  nodump   512 Nov 26 17:35 src-16
drwxr-xr-x  26 lloyd  wheel  nodump  1024 Oct 27 11:07 src-current
bash-2.05b# df -k /data
Filesystem  1K-blocks     Used     Avail Capacity  Mounted on
/dev/wd0h    12848310  8782921   3422973    71%    /data

dump -a -h0 -u -9 -f data_$stamp.dump /data

I write these backups to a multi-session CD and here is what I get
(the first file is a level 0 dump).

archangel# ls -l /cdrom
total 432882
-r-xr-xr-x  1 root  wheel    8745790 Dec 25 00:29 data_2003_12_25_0020_dump.lzo
-r-xr-xr-x  1 root  wheel    3257164 Dec 27 00:28 data_2003_12_27_0020_dump.lzo
...
-r-xr-xr-x  1 root  wheel    1797525 Jan 10 00:18 data_2004_01_10_0010_dump.lzo
-r-xr-xr-x  1 root  wheel  126787422 Jan 11 00:21 data_2004_01_11_0010_dump.lzo

Holy crap! What's in the dump of Jan 11? Don't know, but here is what
get from dump today.

bash-2.05b# dump -a -h0 -9 -f data.dump /data
...
  DUMP: Average transfer rate: 2511 KB/s
  DUMP: Closing data.dump
  DUMP: DUMP IS DONE
bash-2.05b# ls -l
total 429744
-rw-r--r--  1 root  operator  439828480 Jan 21 20:59 data.dump
bash-2.05b# restore -tvf data.dump 
Verify tape and initialize maps
Tape block size is 32
Dump   date: Wed Jan 21 20:47:50 2004
Dumped from: Thu Dec 25 00:20:13 2003
Level 9 dump of /data on ophidian.must-have-coffee.gen.nz:/dev/rwd0h
Label: none
Extract directories from tape
Initialize symbol table.
dir          2  .
dir    2017728  ./htdocs
dir    2021705  ./htdocs/lloyd
leaf   2021779  ./htdocs/lloyd/xgrid-2.1.tar.gz
dir    1267776  ./cvs
dir    1267777  ./cvs/CVSROOT
leaf   1267805  ./cvs/CVSROOT/history
leaf   1267817  ./cvs/CVSROOT/val-tags
dir    1267779  ./cvs/software
dir    1287618  ./cvs/software/xgrid
dir    1289611  ./cvs/software/xgrid/Xbae
leaf   1289645  ./cvs/software/xgrid/Xbae/main.c,v
leaf   1289894  ./cvs/software/xgrid/Xbae/Makefile.in,v
leaf   1289972  ./cvs/software/xgrid/Xbae/configure.in,v
leaf   1289973  ./cvs/software/xgrid/Xbae/install-sh,v
leaf   1289971  ./cvs/software/xgrid/Xbae/config.sub,v
leaf   1289897  ./cvs/software/xgrid/Xbae/config.guess,v

None of those files are overly large. The really big file in there is
58KB. I've double checked, and the dump file doesn't seem to be
sparse. I think I have enough space on my backup spool disk to keep
this file around.

>How-To-Repeat:

Just run dump -a -h0 -9 -f data.dump /data

>Fix:

This can be worked around by making a level 0 dump. This seems to
reset the crazines, at least until next time.
>Release-Note:
>Audit-Trail:
>Unformatted:

Home	PR Database Search