On Fri, Apr 06, 2007 at 08:41:56PM -0400, 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.
>
I suspect that a file is defined by the combination of its inode # and
device id (maj,min). If you take away consideration of the device id,
then lots of files would be defined by the same, non-unique inode #.
If all you took away were consideration for the maj device number,
then systems with unique maj numbers for ide, sata, scsi, usb, ...
could have files with the same remaining identifier (min, inode #).
Unless there was a switch to something like the uuid (universal, unique id)
scheme (which is hardly universal ;) I suspect we are stuck with device &
inode # to define a file.
--
Jon H. LaBadie jon AT jgcomp DOT com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
|
