Bug 16466 - dump fails on large files
dump fails on large files
Product: Red Hat Linux
Classification: Retired
Component: dump (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Preston Brown
Depends On:
  Show dependency treegraph
Reported: 2000-08-17 14:52 EDT by Joshua Buysse
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-08-19 10:08:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joshua Buysse 2000-08-17 14:52:46 EDT
Dump will fail with a file larger than 2GB.  Using the 2.2.16-xxenterprise 
kernel, create a file larger than 2GB.  Dump will not back it up properly, 
it's assuming the old ext2 semantics of a signed 32-bit integer for a file 
size.  When restored, a 3GB file became 49KB.  

Reproduce:  otherwise empty fs, create a file that's > 2GB.  I did a dd 
if=/dev/random of=largefile bs=1M count=3072 -- not the most efficient 
way, but it works.  Then, dump the filesystem (dump 0f target-
dev /dev/hdxx) and it's done in a remarkably short time.  Restore brings 
back a much smaller file.

I'd call this a must-fix, personally.  Bad backups aren't likely to be 
looked on happily.
Comment 1 Joshua Buysse 2000-08-17 15:36:49 EDT
Just as a side note, it might be a good idea to document that other backup 
software like BRU needs to be updated as well.  Trying to back up the same file 
with bru 15.1, I get this (largefile is 3GB):

bru: [W013] "/nfs/brute/d1/vol/t/largefile": can't stat: errno = 75, Value too 
large for defined data type
Comment 2 Glen Foster 2000-08-18 09:04:06 EDT
Additional Info posted to testers-list by John on 17-Aug-2000:

Filesystem was created by anaconda, I didn't recreate it with the
enterprise kernel.  Here's the output of tune2fs:

Filesystem volume name:   /nfs/brute/d1
Last mounted on:          <not available>
Filesystem UUID:          06ceb046-568a-11d4-82dc-f070a7c67f5c
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      filetype sparse_super large_file
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              2660160
Block count:              5313490
Reserved block count:     265674
Free blocks:              4442793
Free inodes:              2660145
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16320
Inode blocks per group:   510
Last mount time:          Thu Aug 17 11:28:59 2000
Last write time:          Thu Aug 17 14:05:34 2000
Mount count:              2
Maximum mount count:      20
Last checked:             Wed Aug 16 15:35:28 2000
Check interval:           15552000 (6 months)
Next check after:         Mon Feb 12 14:35:28 2001
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128

Comment 3 Stelian Pop 2000-08-18 17:28:31 EDT
Ok, we have two bugs here:

1. There is a small bug for files between 2 and 4 GB, a small patch to
is below.  Please test it (I've done just some minimal testing...)

2. For files bigger than 4 GB, I need to change the dump structure on tape to
support 64bit sizes. The change itself is rather simple but I'm not sure if some
parts of dump or restore will not break. So I'll delay this change for
dump-0.4b19, taking the time to test this in a real-world situation (difficult
to test dumps and restores of files bigger than 4 GB on my 10 GB disk :)


Here is the patch for the files between 2 and 4 GB ->

--- traverse.c.old	Sun May 28 20:16:42 2000
+++ traverse.c	Fri Aug 18 23:14:27 2000
@@ -84,10 +84,14 @@
 #define	HASDUMPEDFILE	0x1
 #define	HASSUBDIRS	0x2
+#ifdef  __linux__
+typedef u_quad_t fsizeT;
 #ifdef	FS_44INODEFMT
 typedef	quad_t fsizeT;
 typedef	long fsizeT;
 #ifdef	__linux__
Comment 4 Preston Brown 2000-08-30 14:36:26 EDT
fixed for 7.0 final.

Note You need to log in before you can comment on or make changes to this bug.