Bug 111782

Summary: [ufs] dump(8) fails horribly for large filesystems
Product: Base System Reporter: Steve Chan <sychan>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Open ---    
Severity: Affects Only Me    
Priority: Normal    
Version: 6.2-RELEASE   
Hardware: Any   
OS: Any   

Description Steve Chan 2007-04-17 20:00:08 UTC
The dump command misreports the dumpsize on large filesystems (seems to
work for filesystems up to 283GB, but definitely fails for filesystems
of 680GB), and generates bogus dumps for these large filesystems.

Here is output from dump reporting on dump sizes for 2 filesystems, along
with a df summary of those two filesystems:

sigma# df -k /bro /log
Filesystem  1K-blocks      Used     Avail Capacity  Mounted on
/dev/ad0s1h  14487150    280132  13048046     2%    /bro
/dev/da0g   680876920  43297592 583109176     7%    /log
sigma# /sbin/dump -0 -L -S /bro
  DUMP: Date of this level 0 dump: Tue Apr 17 11:29:19 2007
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping snapshot of /dev/ad0s1h (/bro) to /dev/sa0
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 280959 tape blocks on 7.19 tape(s).
sigma# /sbin/dump -0 -L -S /log
  DUMP: WARNING: -L requested but snapshot location /log/.snap
  DUMP:          is not a directory: dump downgraded, -L ignored
  DUMP: Date of this level 0 dump: Tue Apr 17 11:29:39 2007
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/da0g (/log) to /dev/sa0
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 633671689 tape blocks on 15278.33 tape(s).

Doing a little math on the results based on the # of blocks that dump is
reporting, and on the actual blocks used by df, it looks like dump is
hugely overreporting the amount of space needed. Dump thinks the larger
filesystem dump is over 2000x the size of the smaller one, while based
on the output from df, it is only 150x larger:

sigma# bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
scale = 2
633671689 / 280959
2255.38
43297592 / 280132
154.56

   We see this problem whether we use the -L flag to dum or not.
sigma# /sbin/dump -0 -L -S /log
  DUMP: WARNING: -L requested but snapshot location /log/.snap
  DUMP:          is not a directory: dump downgraded, -L ignored
  DUMP: Date of this level 0 dump: Tue Apr 17 11:40:12 2007
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/da0g (/log) to /dev/sa0
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 633671689 tape blocks on 15278.33 tape(s).
sigma# /sbin/dump -0 -S /log
  DUMP: WARNING: should use -L when dumping live read-write filesystems!
  DUMP: Date of this level 0 dump: Tue Apr 17 11:40:47 2007
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/da0g (/log) to /dev/sa0
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 633671689 tape blocks on 15278.33 tape(s).

The backups that are actually generated by dump are way too big and cannot
be used. We have several filesystems of the same size on this machine, and
the problem occurs on all of them. Smaller filesystems backup fine. The
filesystems are ufs, with soft-updates and local.

At this point, we cannot do any backups of our larger filesystems using the
dump command. We did not see this issue when we ran the same exact hardware under FreeBSD 4.10.

How-To-Repeat: 
Try running dump on a filesystem that is at least 680GB in capacity.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2009-05-18 03:58:36 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:58:28 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