bug-tar
[Top][All Lists]
Advanced

[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"

Attachment: testsuite.log
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]