On 2007-09-27 18:07, John E Hein wrote:
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).
It's even simpler.
Go to the client, and locate the gnutar-lists directory there.
That is the place where Amanda store the incremental-stamps of
gnutar.
Each file begins a number (epoch time stamp in seconds of start of that
run) followed by lines like:
64768 292933 ./usr/kerberos/man
That first number is the device number (major * 256 + minor).
The second number is the inode number of the file.
The problem that you noticed is that an incremental level is the
same as the level 0 backup. So compare the device entries
of the level 0 and the incremental level that was too large.
If the device numbers are the same, then you hit another problem.
I'm curious.
Version of Tar is also important as different versions use different
formats. The format above is "format 0", and is used by gnutar versions
up to 1.15.1. There is also a "format 1", and a "format 2", see:
http://www.gnu.org/software/tar/manual/html_node/Snapshot-Files.html#Snapshot-Files
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?
Not known to me. But very interested.
Try to keep the device numbers the same. :-)
Or hand-edit those gnutar incremental state file with a small perl
program to update the devicenumbers.
--
Paul Bijnens, xplanation Technology Services Tel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512
http://www.xplanation.com/ email: Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************
|
