* Jon LaBadie <[EMAIL PROTECTED]> [20051101 16:02]: > On Tue, Nov 01, 2005 at 02:55:28PM -0500, Scott R. Burns wrote: > > I observed this same issue with: > > > > 2.4.4p4 > > NetBSD/i386 > > HP DAT24*6 > > > > My last DLE was > than the remaining tape, but would fit entirely on the > > next empty tape in the changer as it was the only remaining DLE. It was > > reported as retrying but never did. In this case my holding space was < the > > compressed size of this DLE but it would fit onto tape. > > > > So it was writing direct to tape. And after the initial failure > did not retry. Sounds like the same situation Jeff Allison > describes in the thread "spanning tapes". > > > Ultimately I found enough drive space to reserve for a holding space > than > > this DLE size but I would like to gain that back if this issue could be > > fixed. > > I wonder what is the best approach to a "failed" dump. Note, it is > not a failed taping such as would occur if the taping were coming > from the holding disk. The reason for the dump failure was tape > related, but the dump did fail. > > Is it reasonable to restart the entire dump of the DLE? > Are there any other "dump" failures that are retried?
To the first question: yes, as long as the dump takes lees than dtimeout as I'm saying below. About the 2nd one I'll just say something about dump failures that are *not* retried. I've seen dump failures because of holdding disk attrition: there was plenny of space at the beginning of the backup run but since I have many amanda configurations competing for holdding disk resources, in the event that it fills up the DLE that was migrating to tape will fail and there won't be a retry. I'm not quite sure how such a situation should be deal with as I know that my setup is far from being 'standard'. This being said maybe something like 'well, looks like /holddisk is full, so let's retry with a dump direct to tape' would make sense? > > GH pointed out that Jeff's total dump time was over 15 hours. > As the failed DLE was the only large (and I think only remote) > DLE, most of those 15 hours were spent on the one dump. Should > another 15 hours be expended on the retry of a failed dump? > > Just soliciting opinions. I believe this should be dealt with a proper/meaningful value for dtimeout. In the case I presented above the dump took something like 3hr before failing only because amanda had no way of knowing which DLEs made it to tape and how much tape capacity had been used before the failed one. I certainly would want to see a retry in a case like this because the 'failed' DLE *can* fit in a tape and amanda should try as hard as she can to write the DLE to tape-- as long as it takes less than dtimeout. jf > > -- > Jon H. LaBadie [EMAIL PROTECTED] > JG Computing > 4455 Province Line Road (609) 252-0159 > Princeton, NJ 08540-4322 (609) 683-7220 (fax)