Amanda-Users

Re: testing a patched tar question.

2007-04-07 01:31:22
Subject: Re: testing a patched tar question.
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: amanda-users AT amanda DOT org
Date: Sat, 07 Apr 2007 01:25:11 -0400
On Saturday 07 April 2007, Frank Smith wrote:
>Gene Heskett wrote:
>> Greetings;
>>
>> I don't know if everyone has been following the trail of tears
>> regarding doing backups with the newer kernel versions, but there is a
>> gotcha coming up.  There needs to be a patch applied to the linux
>> kernel that takes the hard drive device major numbers out of the
>> experimental area as defined by a document called LANANA.  This move
>> the ide device number from the major 253 to the major 238 in the
>> /dev/major,minor numbers scheme.
>>
>> This *should* not have an effect on tar, but it does.  Rebooting to
>> one of these newer kernels, or back to an older kernel if the newer
>> one has been running for a few backup sessions results in the Device:
>> hex/decimal values changing when doing a 'stat' on a file.  Tar treats
>> this as an indicator that the data is brand new and must therefore be
>> given a level 0 backup.  Of course our typical tape size, affordable
>> by home users such as I, doesn't approach being able to handle a
>> single backup of nearly 50GB, the best we can do is raise heck with
>> our schedule by doing 2 or 3 backup sessions with as large a tapetype
>> size setting as we have combined vtape and holding disk area to
>> handle.
>>
>> My view is that since the inode data doesn't change, and the files
>> timestamps don't change just because I've rebooted to a different
>> kernel, that tar is miss-firing on this when asked to do a
>> --listed-incremental and the reference file furnished was built under
>> a different kernel with a different major device number for the
>> ide/atapi drives.
>>
>> Ok, that's the background as I try to head off what could be an
>> upgrade disaster that I now know about, but which will scare the
>> bajezus out of someone who isn't ready for it.  As of 2.6.21-rc6, that
>> patch has been reverted while the details of how to do this with less
>> disturbance are being worked out.  I've also queried the guys listed
>> in the tarballs ChangeLog just this afternoon after it became obvious
>> that bugs AT gnu DOT org, a moderated list, wasn't being moderated in a
>> timely manner.
>>
>> I've downloaded, from gnu.org, the latest tarball snapshot,
>> 1.16.2-20070123, and installed a 1 line patch that removes this
>> Device: sensitivity.
>>
>> I also don't know but what I may have opened that proverbial can of
>> worms either.  Since nothing in the file or filesystem has actually
>> changed, I view this sensitivity to the device major numbers as a bug,
>> but there may in fact be a very good reason for it that I'm not aware
>> of.  If there is, then someone should make me aware of the reasons
>> that this is a part of tars logic.
>>
>> At any rate, this new tar works with my testing scripts when executed
>> insitu in its build tree, and the only fuss when doing a 'make test'
>> in the src tree is a claim that the exclude function failed.  That I
>> could tolerate I think, at least long enough to test.
>>
>> To that end, I modified my configure script to point at this new
>> version of tar, and did the usual install here.  That appears to have
>> succeeded.
>>
>> What I want to know from all of you, is do I push to get this patch
>> into tar, or how else should we attempt to reduce the pain here? Let
>> me emphasize that once amanda has been able to make all new level 0's
>> of your data, then amanda will settle down and this will be just
>> another bump in the road.
>
>I would be hesitant to push for that change.  However inconvenient it
>might be as a result of a kernel upgrade, a new major number is a new
>device, and to ignore it changing is inviting disaster.
>   You would need to look at tar's code to see how it's using the device
>number, it might have an effect on the --one-file-system option.
>
>Frank
>
>> So lets talk, please.  In the meantime I have a test backup running
>> for effect...

And the test run wasn't as I anticipated, leaving behind some timestamps 
that were invalid when I reverted to the usual tar.  It also appeared to 
want to back it all up in one swell foop.  So maybe this trail is best 
abandoned after all.

-- 
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)
If I could drop dead right now, I'd be the happiest man alive!
                -- Samuel Goldwyn