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.
So lets talk, please. In the meantime I have a test backup running for
effect...
--
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)
At the end of your life there'll be a good rest, and no further activities
are scheduled.
|
