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: Always Steps to Reproduce: 1.dump -0u -B300000 -M -ffoo.dmp. /dev/sdaX 2.dump 3uMfBb foo-3.dmp. 500000 1 /dev/sdaX 3. 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 dump-0.4b25-1.71.0 # 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 :-( TIA, Stelian.
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...)
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) Stelian.
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. Oops... 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...