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?