Re: sendbackup with dumplevel 0 takes a while to startup :-{
>Problem with this is obtaining a definitive PROOF. Welcome to my world. >you do the amanda process, and you notice that the tape is not spinning, >even though you are in the sendbackup phase. ... It might not be spinning if you have enough holding disk that the image is going there first. However I gather that's not the case with your system, so this means taper is not getting any data from the client. Moving further back in the chain ... >You notice that the ethernet switch is not blinking. ... Which matches the above and also says the client is not even trying. So we continue to move on back ... >You can also notice the task(s) that are running. ... So it's not that they just died, so now we move forward a bit from the far end ... >You also notice that the disk controller light is light. Are you saying the disk is "busy"? If so, then it's likely tar (or the OS) is grinding away but not generating any data into the pipeline to Amanda (sendbackup), as you've already pretty well guessed. So this is purely a tar (or OS or hardware) issue. If you did exactly the same thing by hand that Amanda is asking tar to do, it would act the same way. What's going on here is totally independent of Amanda. Next would be to run truss or a debugger on tar and find out what it's up to, then talk to those folks. >You can make some general conclusions, like gee the reason i up'ed the >destimate value from 30min to 6hours is due to what is occuring now. ... You upped that value as a workaround for something very, very odd/bad with the way tar is working on your system. >/gat John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: sendbackup with dumplevel 0 takes a while to startup :-{
Problem with this is obtaining a definitive PROOF. you do the amanda process, and you notice that the tape is not spinning, even though you are in the sendbackup phase. You notice that the ethernet switch is not blinking. You can also notice the task(s) that are running. You also notice that the disk controller light is light. You can make some general conclusions, like gee the reason i up'ed the destimate value from 30min to 6hours is due to what is occuring now. I dont know why, or all of the facts, but i do notice thats it's idle. and i do notice transfer timeouts, although i dont know why exactly either - yet. /gat "John R. Jackson" wrote: > > >according to the tar docs, the --listed-incremental will check on the > >files listed in the file if the incremental file is not empty. I suppose > >the listed-incremental file got filled during the sendsize proceedure?! > > No. It got filled by the previous sendbackup run (e.g. yesterday). > > And, FYI, for a level 0 (full) dump, the listed incremental file comes > from /dev/null, i.e. it is used, but empty. > > >During the sendbackup step, tar is apparently going through and checking > >the list, as no data is being transmitted while tar is doing this check. > > I'm not sure exactly how tar does this. You'd have to look at their > code or ask them. I'd be surprised if it completely lost it for 30 > minutes, though. > > >Is this how its suppose to work for a level 0 dump? ( 4 hours > >(wall-time) sendsize, ~4hours (wall-time) incremental check, and finally > >the transfer of the data ( i suppose longer that 4 hours )) ... > > Probably true. > > >Is this how > >it will work with other level dumps ( with the exception of the transfer > >of data step) ? > > Yes. Except Amanda may also request a third estimate one level higher > than the previous one if it might be time to bump (you can control this > with the bump* parameters). > > You might want to consider using an alternate size calculation tool called > calcsize. It's not well supported, and does not handle exclusion lists, > but does all the estimates at the same time so you might gain quite a > bit of time that way. > > If you want to go this route, let me know and I'll find the postings > from a while back about turning it back on. > > >/gat > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: sendbackup with dumplevel 0 takes a while to startup :-{
>according to the tar docs, the --listed-incremental will check on the >files listed in the file if the incremental file is not empty. I suppose >the listed-incremental file got filled during the sendsize proceedure?! No. It got filled by the previous sendbackup run (e.g. yesterday). And, FYI, for a level 0 (full) dump, the listed incremental file comes from /dev/null, i.e. it is used, but empty. >During the sendbackup step, tar is apparently going through and checking >the list, as no data is being transmitted while tar is doing this check. I'm not sure exactly how tar does this. You'd have to look at their code or ask them. I'd be surprised if it completely lost it for 30 minutes, though. >Is this how its suppose to work for a level 0 dump? ( 4 hours >(wall-time) sendsize, ~4hours (wall-time) incremental check, and finally >the transfer of the data ( i suppose longer that 4 hours )) ... Probably true. >Is this how >it will work with other level dumps ( with the exception of the transfer >of data step) ? Yes. Except Amanda may also request a third estimate one level higher than the previous one if it might be time to bump (you can control this with the bump* parameters). You might want to consider using an alternate size calculation tool called calcsize. It's not well supported, and does not handle exclusion lists, but does all the estimates at the same time so you might gain quite a bit of time that way. If you want to go this route, let me know and I'll find the postings from a while back about turning it back on. >/gat John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
sendbackup with dumplevel 0 takes a while to startup :-{
according to the tar docs, the --listed-incremental will check on the files listed in the file if the incremental file is not empty. I suppose the listed-incremental file got filled during the sendsize proceedure?! During the sendbackup step, tar is apparently going through and checking the list, as no data is being transmitted while tar is doing this check. with a dtimeout of 30 minutes, i would get this unexpected timeout. Is this how its suppose to work for a level 0 dump? ( 4 hours (wall-time) sendsize, ~4hours (wall-time) incremental check, and finally the transfer of the data ( i suppose longer that 4 hours )) Is this how it will work with other level dumps ( with the exception of the transfer of data step) ? /gat 10690 ?S 0:00 /usr/local/libexec/sendbackup 10691 ?S 0:00 /usr/local/libexec/sendbackup 10692 ?D 1:37 gtar --create --file - --directory /mnt/hdg3 --one-file-system --listed-incremental /usr/local/var/amanda/gnutar 10693 ?S 0:00 sh -c /bin/gtar -tf - 2>/dev/null | sed -e 's/^\.//' 10694 ?S 0:01 /bin/gtar -tf - PWD=/tmp/amanda HOSTNAME=LX MACHTYPE=alpha-redhat-linux-gnu SHLVL=1 SHELL=/bin/bash HOSTTYPE=alp 10695 ?S 0:00 sed -e s/^\.// PWD=/tmp/amanda HOSTNAME=LX MACHTYPE=alpha-redhat-linux-gnu SHLVL=1 SHELL=/bin/bash HOSTTYPE=alph
