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...
>
--
Frank Smith fsmith AT hoovers DOT com
Sr. Systems Administrator Voice: 512-374-4673
Hoover's Online Fax: 512-374-4501
|
