Bug 64091 - Incremental dump using /sbin/dump dumps everyting
Incremental dump using /sbin/dump dumps everyting
Product: Red Hat Linux
Classification: Retired
Component: dump (Show other bugs)
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2002-04-25 12:08 EDT by steve
Modified: 2007-04-18 12:42 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-26 04:52:53 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 steve 2002-04-25 12:08:54 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):

How reproducible:

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,
level3, dump.

Additional info:

/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
Comment 1 Stelian Pop 2002-04-25 15:26:00 EDT
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 :-(


Comment 2 steve 2002-04-25 21:20:21 EDT
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 think...)
Comment 3 Stelian Pop 2002-04-26 04:52:49 EDT
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)

Comment 4 Mike A. Harris 2002-04-28 12:24:26 EDT
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.
Comment 5 steve 2002-04-28 15:19:00 EDT
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[1] % stat whiteblack.png 
  File: "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
straight now.

Apologies for the unnecessary burden. Now I just need to figure
out how to fix the Change: stamps on all these files...

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