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 [EMAIL PROTECTED], 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.
