[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-tar] [GNU tar 1.16.2] testsuite: 12 failed, was "tar vs later linux
From: |
Gene Heskett |
Subject: |
[Bug-tar] [GNU tar 1.16.2] testsuite: 12 failed, was "tar vs later linux kernels" |
Date: |
Fri, 06 Apr 2007 15:31:10 -0400 |
User-agent: |
KMail/1.9.6 |
Greetings;
Some small additions to the first, as yet un-acknowleged message.
And then some more as I attempt to find a fix for this problem.
Recently, a patch was applied to the linux kernel tree which had the
effect of changing the Device: line of a 'stat' report on a file.
The inode did not change, nor did the timestamps, only the Device: first
pair of values.
----
Added: A cat /proc/devices shows the device-mapper at address 238, where
it had been in the LANANA experimental range at 252. This patch has now
been reverted as of 2.6.21-rc6, so as an amanda user, I will have to do
several backup runs today, needlessly filling my vtapes drive as if all
the data was new, until it has made full backups of the complete system.
----
Device: ee00h/60928d <-all other data is identical regardless of the
kernel booted.
This has the effect that tar, when asked to give a listed-incremental list
and fed the reference file so it can obtain the timestamps and determine
if the file is new, would ascertain that the whole 50GB of a 160GB drive
that was used, was new, and drove amanda crazy trying to get caught up.
This patch needs to be applied to the kernel for good reasons as it moves
the device-mapped stuff out of an area that is reserved for experimental
usage.
What I looking for, is a good reason why tar is in fact sensitive to this
particular piece of info in the first place.
And of course, would it be possible to make tar immune to this change, as
I, with my relative lack of information, consider this to be a bug. If
its not fixed, tar users such as myself using amanda, are in for a very
rude surprise when the upgrade their kernels to something newer than
2.6.20.3.
----
Added:
It has now been 22 hours since my first post to you, with no reply as yet,
and I was hoping to have this issue resolved before 2.6.21 final is out.
----
Even later, I have downloaded and walked around in the 1.16.2 snapshot
dated 20070123.
In src/compare.c, line 320, I have commented out the active part of that
continued conditional statement. As follows:
src/compare.c line 320
/*&& current_stat_info.stat.st_rdev != stat_data.st_rdev*/)
with no other changes to the code tree, followed by a ./configure with no
arguments, a make, and a make test.
The make test fails for item 12, the exclude function. As per the message
at the end of the test, I have attached the logs.
What deleterious effect will my patching of that line have, and is the
loss of the exclude a real loss? My amanda backup schedule does make use
of the excludes directive.
I'm now off to actually test this, supposedly immune to device-mapper
moves, version of tar, and will report if it actually works as expected.
It would also be nice if this was not a monolog. To that end, I've also
Cc:'d the two most often credited developers from the ChangeLog
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Zoe: "Sir, I think you have a problem with your brain being missing."
--Episode #2, "The Train Job"
testsuite.log
Description: Text Data
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Bug-tar] [GNU tar 1.16.2] testsuite: 12 failed, was "tar vs later linux kernels",
Gene Heskett <=