Re: 110%?
On Jan 21, 2001, Ben Elliston [EMAIL PROTECTED] wrote:
My tip of the week: don't back up the holding disk. :-)
Or use a dumptype with `holdingdisk no' for the holding disk, in case
it contains useful data.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
110%?
amstatus says that one of my partitions has been dumped to 110%. Then it just sits there, never writing the dump to tape (there are no tapers running). scooby:sda5 0 127811k dumping 141056k (110.36%) What's up with this? I'm running CVS Amanda on the tape server now. Thanks, B.
Re: 110%?
On Sun, 21 Jan 2001, Ben Elliston wrote: amstatus says that one of my partitions has been dumped to 110%. Then it just sits there, never writing the dump to tape (there are no tapers running). scooby:sda5 0 127811k dumping 141056k (110.36%) What's up with this? I'm running CVS Amanda on the tape server now. It's possible to go past 100% if the filesystem grows between when the estimate is performed and when the dump finishes. The above says that amstatus thinks the dump is still running. Does amanda still have processes running on scooby? -Mitch
Re: 110%?
On Sun, Jan 21, 2001 at 10:54:05AM +1100, Ben Elliston wrote: amstatus says that one of my partitions has been dumped to 110%. Then it just sits there, never writing the dump to tape (there are no tapers running). scooby:sda5 0 127811k dumping 141056k (110.36%) What's up with this? I'm running CVS Amanda on the tape server now. It means the estimate (127811k) was wrong and the filesystem is larger than the estimate. It must be dumping something, look for process activity on your client and server. Jean-Louis -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
Re: 110%?
It means the estimate (127811k) was wrong and the filesystem is larger than the estimate. It must be dumping something, look for process activity on your client and server. There are five concurrent dump processes running for /dev/sda5: 404 ?S 0:00 dump 0usf 1048576 - /dev/sda5 408 ?S 0:00 dump 0usf 1048576 - /dev/sda5 409 ?S 0:01 dump 0usf 1048576 - /dev/sda5 410 ?S 0:01 dump 0usf 1048576 - /dev/sda5 412 ?S 0:01 dump 0usf 1048576 - /dev/sda5 They don't seem to be doing much: [root@scooby /root]# strace -p 404 wait4(-1, unfinished ... [root@scooby /root]# strace -p 408 read(19, unfinished ... [root@scooby /root]# strace -p 409 pause( unfinished ... [root@scooby /root]# strace -p 410 write(1, "%\317\301[\4\364s\6\227\245\312\250\307-\354\247\2\225"..., 6144 unfinished ... [root@scooby /root]# strace -p 412 pause( unfinished ... Processes 408 and 410 *are* in read/write calls, but they're not doing much. Is something wedged, and if so, why? Ben
Re: 110%?
On Sun, 21 Jan 2001, Ben Elliston wrote: Processes 408 and 410 *are* in read/write calls, but they're not doing much. Is something wedged, and if so, why? Are you using compression? If so gzip could well be the bottleneck rather than dump. Look for gzip processes, too. To decide if something's wedged, look at your holding disk(s) and see if the file there is growing. -Mitch
Re: 110%?
On Sun, Jan 21, 2001 at 11:36:12AM +1100, Ben Elliston wrote: Processes 408 and 410 *are* in read/write calls, but they're not doing much. Is something wedged, and if so, why? What's the dumper is doing on the server? Do you have free space on your holding disk? Are you sure you are running 2.4.2, not 2.5.0? (amadmin conf version) Jean-Louis -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
