|
Re: Amflush Problem - Again!
2006-03-04 01:05:11
Hello:
About your questions about clipping the contents - No, that's the full
uncensored log/output of amflush :)
And about the problem, I found the solution - a weird one. I moved stuff
from 20060216 out of the holding space to some other place and then amflush
worked. I am wondering what could be going wrong here. I haven't still tried
amflushing 20060216 contents to the tape yet, but I feel it might just work
too. I post the results to this list soon.
But, what is making amflush not flush data to tape? Incase if it is facing
problems maybe from OS or with something else, shouldn't it complain?
Regards,
Rohit
----- Original Message -----
From: "Gene Heskett" <gene.heskett AT verizon DOT net>
To: <amanda-users AT amanda DOT org>
Sent: Friday, March 03, 2006 10:22 PM
Subject: Re: Amflush Problem - Again!
On Friday 03 March 2006 09:01, Jon LaBadie wrote:
I have no suggestion Rohit, But a question for developers.
Amflush output:
-bash-2.05b$ /usr/sbin/amflush -f DailySet1
Scanning /backup/amanda_hold/DailySet1...
20060216: found Amanda directory.
20060223: found Amanda directory.
20060302: found Amanda directory.
Multiple Amanda directories, please pick one by letter:
A. 20060216
B. 20060223
C. 20060302
Select directories to flush [A..C]: [ALL] B C
Today is: 20060303
Flushing dumps in 20060223, 20060302 to tape drive "/dev/nst0".
Expecting tape TLS-Set-1-05 or a new tape. (The last dumps were to
tape TLS-Set
-1-04)
Are you sure you want to do this [yN]? y
amflush: datestamp 20060303
driver: pid 15642 executable driver version 2.4.3
driver: send-cmd time 0.005 to taper: START-TAPER 20060303
driver: adding holding disk 0 dir /backup/amanda_hold/DailySet1 size
2234040 reserving 2234040 out of 2234040 for degraded-mode dumps
taper: pid 15643 executable taper version 2.4.3
taper: page size is 4096
taper: buffer size is 32768
taper: buffer[00] at 0x400d5000
taper: buffer[01] at 0x400dd000
taper: buffer[02] at 0x400e5000
taper: buffer[03] at 0x400ed000
taper: buffer[04] at 0x400f5000
taper: buffer[05] at 0x400fd000
taper: buffer[06] at 0x40105000
taper: buffer[07] at 0x4010d000
taper: buffer[08] at 0x40115000
taper: buffer[09] at 0x4011d000
taper: buffer[10] at 0x40125000
taper: buffer[11] at 0x4012d000
taper: buffer[12] at 0x40135000
taper: buffer[13] at 0x4013d000
taper: buffer[14] at 0x40145000
taper: buffer[15] at 0x4014d000
taper: buffer[16] at 0x40155000
taper: buffer[17] at 0x4015d000
taper: buffer[18] at 0x40165000
taper: buffer[19] at 0x4016d000
taper: buffer structures at 0x40175000 for 240 bytes
taper: read label `TLS-Set-1-05' date `X'
taper: wrote label `TLS-Set-1-05' date `20060303'
Why is so much detail being shown to the user of amflush?
Do they really care about the taper buffers?
Do they really care that the driver is starting taper?
Aren't those messages more suitable for a silent log file
or a debug file?
BTW driver seems like it is doing unneeded things for
an amflush, like setting a degraded mode, allocating
holding disk, ...
I agree Jon, this is too much detail and not enough info at the same
time. To the original poster Rohit: Did you purchance clip it off
just about the place where it might have gotten interesting? I feel
that what we want to know may be there, but we didn't get to see it.
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
|
|
|
