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 [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 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.
