John E Hein wrote at 09:43 -0600 on Sep 27, 2007: > Dustin J. Mitchell wrote at 21:14 -0500 on Sep 26, 2007: > > Just a guess -- is this a Linux machine that recently had hardware > > added/removed? > > linux, no - freebsd. devno changes? I don't think so. There was a > raid disk replacement. But that's a hidden device behind an LSI > Megaraid controller that exports the raid as a scsi device. > > > If so, the device numbers may have changed for that partition, leading > > tar to think that all files have been changed. Gene Heskett chased > > down such a bug several months ago. > > I'll check for devno changes on the scsi device.
This sounds like the most likely explanation, but I can't verify. I can't think of any way to see if they changed - I don't have a record of what they were before. Is there a way to look in the gnutar-list files and see? I suppose I will extract the tar files off tape and extract devno from the archive (howto hints for getting the devno from tar archives welcome). This is FreeBSD 6 which does have devfs, so it's entirely possible, but other than the invisible behind-the-raid-controller disk change, nothing else changed. PCI devs should have enumerated the same - nothing was moved around in the slots. Next time I do something like this, I'll check before/after listings of /dev. Now... let's say the devno did change, and I noticed and know what it is before and after. What's the best way to avoid the inevitable incremental dump of everything? I don't see a way to tell gnutar to ignore the devno. Is there one? If so, is there a better way?
