This is the dumptype am using in my disklist file - 'always-full'
}
define dumptype always-full {
global
comment "Full dump of this filesystem always"
compress none
priority high
dumpcycle 0
}
On Fri, 3 Nov 2000, John R. Jackson wrote:
> I looked at your amdump.1 log and the code for quite a while this
> afternoon and am not sure what happened. It looks like the driver
> algorithm for choosing the next dump to process may have trouble with
> some restricting situations in conjunction with you not using a tape.
> For instance, it looks like the code might decide to send a dump direct
> to tape when there doesn't appear to be enough bandwidth. That does
> not appear to be what's happening to you, but it would cause what you
> are seeing.
>
> There is not enough logging data about why the two disks were not allowed
> to go to the holding disk to tell for sure.
>
> Another thought: are you using the same dumptype for all the disks?
> Is there any chance these two are marked "holdingdisk no" or are different
> in some other way? At one point, when your holding disk was going to be
> part of /home, I told you you would have to do that. But now that it's
> a separate partition, you should definitely **not** be using this option.
>
> If this isn't it, the only thing I can think of to do is generate some
> temporary patches for your system to better track what is going on.
> But I know how much you enjoy applying patches :-), so you make the call.
>
> John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
>
--
Denise E. Ives [EMAIL PROTECTED]
Systems Engineer 734.822.2037
Multilingual Internet Domain Name Registrations - http://www.walid.com
