On Tuesday 16 March 2004 16:02, Geoff Swavley wrote: >Hi All, > >I was wondering if anyone could tell me why amanda seems to split >my filesystem into 2 "holding" files? An error has occurred so these > filesare left on the disk. Here is the filesystem listing: >at the files: > >46592 1 drwxr-xr-x 4 amanda sys 512 Mar 17 00:45 >/holding2/schedule8 >209664 1 drwx------ 2 amanda sys 512 Mar 13 05:22 >/holding2/schedule8/20040312 >209666 2301584 -rw------- 1 amanda sys 2355658752 Mar 13 > 05:22 /holding2/schedule8/20040312/pokolbin._u20.0.1 >209665 31472648 -rw------- 1 amanda sys 32212254720 Mar 13 > 05:07 /holding2/schedule8/20040312/pokolbin._u20.0 >203840 1 drwx------ 2 amanda sys 512 Mar 17 00:45 >/holding2/schedule8/20040317 > >Has it got something to do with a 32GB limit? What does the ".1" > and ".0" refer to? >Obviously the ".1" ias the 2nd file of the filesystem?? > >thanks all. Here is the error email I received: > >Subject: schedule8 AMANDA MAIL REPORT FOR March 12, 2004 > Date: Sat, 13 Mar 2004 08:26:54 +1100 (EST) > From: Amanda Archiving Server <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [EMAIL PROTECTED] > > >These dumps were to tape schedule8-WEEK3. >*** A TAPE ERROR OCCURRED: [[writing file: short write]]. >Some dumps may have been left in the holding disk. >Run amflush to flush them to tape. >The next tape Amanda expects to use is: schedule8-WEEK4. > >FAILURE AND STRANGE DUMP SUMMARY: > pokolbin /u20 lev 0 FAILED [out of tape] > > >STATISTICS: > Total Full Daily > -------- -------- -------- >Estimate Time (hrs:min) 0:00 >Run Time (hrs:min) 9:41 >Dump Time (hrs:min) 6:34 6:34 0:00 >Output Size (meg) 32966.5 32966.5 0.0 >Original Size (meg) 32966.5 32966.5 0.0 >Avg Compressed Size (%) -- -- -- >Filesystems Dumped 1 1 0 >Avg Dump Rate (k/s) 1426.7 1426.7 -- > >Tape Time (hrs:min) 0:00 0:00 0:00 >Tape Size (meg) 0.0 0.0 0.0 >Tape Used (%) 0.0 0.0 0.0 >Filesystems Taped 0 0 0 >Avg Tp Write Rate (k/s) -- -- -- > >USAGE BY TAPE: > Label Time Size % Nb > schedule8-WEEK3 0:00 0.0 0.0 0 > > >NOTES: > taper: tape schedule8-WEEK3 kb 31851520 fm 1 writing file: short > write driver: going into degraded mode because of tape error. > > >DUMP SUMMARY: > DUMPER STATS TAPER > STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s > MMM:SS KB/s -------------------------- > --------------------------------- ------------ pokolbin /u20 > 0 3375766433757664 -- 394:211426.7 FAILED ---- > >(brought to you by Amanda version 2.4.4p2)
This looks to me as if you ran out of tape. Did you just add these to the disklist? How did you determine the tapetype? Is the tape drives hardware compressor enabled? Amtapetype can determine this and tell you. The latter case in particular can and will hide the true capacity of a tape from amanda. Please understand that amanda counts bytes sent to the drive when making its judgements as to tape fitting. Enabling the drives compressor makes amanda think the tape is much larger than it really is so this users recommendation is and always has been to shut off any hardware compression and use only software compression. Yes, it takes time and cpu horsepower to do software compression, but it can beat the socks off the hardware compressor for most compressable data, sometimes smunching things down to <10% of the original byte count. Since amanda tracks the size of the compressed file, amanda then knows exactly how much has been moved to the media and very very rarely will amanda hit an EOT then. When adding a new path to amanda's disklist, I always set the compression on, then look at the mailed report from the next run. If compression only saved 5 or 10 percent, then that data in that path should be considered as already compressed, like a directory full of rpm's or tar.gz's. Binary executables generally will fall into this category too, so one shouldn't waste the cpu horsepower to even try. OTOH, your /etc dir will probably smunch to <20% of its original size and should be compressed on most systems. Also, keep in mind that amanda, generally speaking, cannot handle a disklist entry thats truely bigger than the tape because amanda cannot, without patching, span a single entry across more than one tape. Because that involves tape operations that amanda may not have full control over, thereby endangering the data, that limitation isn't something the authors are working to fix as its not really considered broken by anyone except the fellow who bought a too small tape drive. Disklist entries can be broken down into smaller pieces if you are using tar, and in your case it appears that would be the recommendation. For instance, I treat each subdir in my 46Gb /usr as a seperate entry, and my 4 tape changer, equipt with a 4Gb DDS2 drive can then handle nearly 70Gb of data with an 8 day dumpcycle. Normally using only 1 tape a nite, tonight is going to be interesting because amanda has been shut down for the last 6 weeks as I've been out of pocket & didn't want to saddle the missus with the tape changing while I was gone. So tonight it gets to use 4 tapes, but will only find 2 unless I reload the magazine, so I'll have to flush in the morning. This will continue till amanda has played catchup. Minor detail, generally speaking. [...] -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.22% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.