On Friday 14 November 2003 09:20, Jay Fenlason wrote:
>On Fri, Nov 14, 2003 at 01:23:12AM -0500, Gene Heskett wrote:
>> Greetings all;
>>
>> See subject, Which of course is leading to a 90% failure rate as
>> the whole system has around 40Gb, but the tapes are only 4Gb's.
>>
>> What happened is that I put in a new 120 Gb drive, 2x the size of
>> the one I took out, mainly because the root partition was full,
>> and no room to readjust things was available.
>>
>> Although the /dev/whatevers have changed, the mountpoints have
>> not.  I used cp to copy some of the data, and fr to do some, seems
>> cp cannot see a .file!
>>
>> I missed one run while the disk was being configured.  One person
>> said he had never swapped disks without doing a re-install, but I
>> just did, and everything seems to be working just fine.  Its
>> tedious for sure, but it can be done.
>>
>> I have expanded the dumpcycle and runspercycle from 8 to 10
>> because it seemed amanda was having a hard time hitting its best
>> balance point. tapecycle is still 28, but I can add more.
>>
>> So the disklist is unchanged.  Why does amanda want to do a level
>> 0 on the whole system?
>
>When you copied the files, the inode numbers for each file changed.
>When gtar sees the inode number of a file change, it assumes the
>contents of the file have changed too (it doesn't store md5sums of
>file data or anything clever like that).  Amanda sees that an
>incremental is the same size as a level 0, so it tries to do a level
>0.
>
>Also, cp/fr may not have correctly reset the modification times of
> the files when it copied them.  Oh, and they may not handle links
> well either.  To copy directory trees, I usually use "( cd /fromdir
> ; tar cf - . ) | ( cd /todir ; tar xpf -)", which preserves
> modification times, and permissions.

Neat.  I'll try to remember that.  Looks like its pure memory for 
buffer usage.

The times reported by an ls -l seem to be sane, and of those perms I 
checked, they were preserved ok.  The major hiccup I had was that cp 
doesn't do ".name" files, and once went wild and copied the whole 2.5 
gig /root directory into /root/.ymessenger/root when I tried to make 
it do it with a different wild card pattern.  And links definitely 
weren't a problem that I've run into since the drive switch.

>Hmm.  How clever do you feel like being?  If you can somehow get a
>list of the files which have actually changed, you could edit the
> last listed-incremental data file and update the inode numbers of
> all the files you don't want to re-dump.  It'd probably be an
> amusing perl script. . .

Chuckle...  "Perl Script?"  Doesn't she live in some town in New 
Mexico? :-)

I have the utmost respect for Larry Wall, but I don't comprehend that 
language at all.  Shell scripts, sometimes old basic, and plain old 
C, I've poked around in the kernel a few times, but perl?  Nuh-huh...  
Its got voodoo spells in it I swear.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.