Red Hat Bugzilla – Bug 64091
Incremental dump using /sbin/dump dumps everyting
Last modified: 2007-04-18 12:42:19 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.18 alpha)
Description of problem:
The /sbin/dump program level 0 works fine, but when I try to do an incremental
dump, it dumps even ancient files, much older then the last level0 dump.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.dump -0u -B300000 -M -ffoo.dmp. /dev/sdaX
2.dump 3uMfBb foo-3.dmp. 500000 1 /dev/sdaX
Actual Results: The foo-3.dmp.* files contain practially a complete dump. Even
old files are stored in it. /etc/dumpdates gets updated properly
Expected Results: I should see only recently changed files in the incremental,
/etc/dumpdates after a dump:
/dev/sdaX 0 Wed Apr 24 17:41:59 2002
/dev/sdaX 3 Thu Apr 25 03:00:03 2002
[root@icarus BACKUPS]# rpm -q dump
# uname -a
Linux icarus.com 2.4.18 #1 Mon Mar 25 14:03:06 PST 2002 alpha unknown
This is an alpha PC164 w/ srm console
I wonder if this could be related to the time_t issues on alpha ? Could you
please download and build the latest version of dump (0.4b28) from the upstream
site http://dump.sourceforge.net and see if you still have those problems.
Unfortunatelly I don't have an alpha to test this myself :-(
I've downloaded the src.rpm of dump-0.4b28-1, and I compiled it with
rpm --rebuild. I have installed e2fsprogs-1.26-1.71 and e2fsprogs-devel
of the same version. The only non-RedHat part of the is the 2.4.18
kernel that I compiled from source. (The 2.4.9 kernels were unstable
on my PC164/srm.)
The level3 dump still behaves the same, dumping far too many files,
including files that are definitely older then the last complete dump.
It is not as big as the complete dump (4 volumes, instead of 7) but
still way wrong. This is the dump command I use (names changed to
protect the innocent):
dump 3uMfBb $WORK/foo-3.dmp. 500000 1 /dev/sdaX
I have the nagging suspicion that e2fsprogs is the root of the problem,
because fsck seems to have a problem that I've reported already.
I don't find any e2fsprogs bugzilla entry regarding your fsck problem, so I
guess you didn't report it yet.
Some directions you may follow:
* try e2fsprogs 1.27 (http://e2fsprogs.sourceforge.net)
* report the fsck problem in bugzilla and give the pointer here, maybe there
is a relation between the two problems
* do a stat(1) on the files you consider 'older than the last complete dump'
and verify that _both_ ctime and mtime are older than the 0-level date as
recorded in /etc/dumpdates (some users reported that some programs, including
antiviruses and konqueror, sometimes open the files to inspect the contents thus
modifiying the ctime)
You're not running the Red Hat Linux kernel, you're running a custom
built kernel. As such, your system is not supported. If you can
reproduce this problem using the current official Red Hat Linux kernel
for Red Hat Linux 7.1 (2.4.9-31 as of this writing) and using a completely
updated system with all security and bugfix errata applied, then we can
further investigate the problem.
Red Hat does not support systems with customized kernels. Feel free to
reopen the bug if the problem persists when using Red Hat supplied software.
I found the problem. My mistake. Let me explain.
With the 2.4.3-12 kernel, and all the other updates
applied, I still see the same problem. For example,
this file always shows up in the level3 dump:
icarus.com % stat whiteblack.png
Size: 734 Blocks: 8 Regular File
Access: (0644/-rw-r--r--) Uid: ( 1045/ steve) Gid: ( 10/ wheel)
Device: 805 Inode: 195628 Links: 1
Access: Thu Apr 25 09:02:12 2002
Modify: Thu Feb 28 15:17:29 2002
Change: Tue Mar 22 10:06:33 2022
... and if you are not looking *very* closely, you would miss
(as did I) that the Change date is 2022, not 2002. How *that*
happened is another mystery, but I have an idea how to set things
Apologies for the unnecessary burden. Now I just need to figure
out how to fix the Change: stamps on all these files...