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
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
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
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
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 -
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
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
