On Wednesday 05 June 2002 05:28 pm, Kenny MacPherson wrote: >Stephen, Jon, Lalo and Gene (and anyone else!) > >Thanks for the response. It's very helpful - I wasn't picking on > you Lalo but when I saw the 24GB quoted, alarm bells started > ringing, so it's good to here that my 55GB should be backup-able. > >As far as the holding disk goes, I only have 35GB disk, and I'm on > 32bit Sol 7. AMANDA is configured to use "chunks" of just under > 2GB each. > >The errors tend to be: > >FAILURE AND STRANGE DUMP SUMMARY: > toronto /home3 lev 0 FAILED [out of tape]
You're walking on ground I haven't, at least on that sort of a scale. My system here is a CTL-96 Seagate drive but only a 4 slot magazine, so I have 3x about 3.7 gb tapes available. Wary of running an individual partition line in the disklist over the capacity of the tape, I've actually specified my /usr by each individual subdir which even keeps the downloads catchall under 3.7 gb. In this manner, I never ask amanda to span to the next tape, and I have sufficient tapes and days in the cycle that it can do 2 to 4 level 0's in each nightly run, getting it all at level 0 in just 3 or 4 days out of the 7 I allow. Amanda cannot span to the next tape with the leftover portion of a file, but will instead backup to the head (of I think that particular 2gb hunk, but it might be to that whole specified line in the disklist), load the next tape and try it again. In that event, a partition spec in the disklist thats larger than the holding area sounds like a recipe for trouble, and you should probably break the disklist up into smaller pieces by specifying it as subdirs, one per line. > taper: FATAL syncpipe_get: w: unexpected EOF > >or > >FAILURE AND STRANGE DUMP SUMMARY: > toronto /home3 lev 0 FAILED [data timeout] > toronto /home5 lev 0 FAILED [out of tape] > taper: FATAL syncpipe_get: w: unexpected EOF > toronto /home5 lev 0 FAILED ["data write: Broken pipe"] > toronto /home5 lev 0 FAILED [dump to tape failed] > >While this points the finger at the EZ17 library, The Mammoth 2 > drive inside it (AFAICT) should take upto 150GB on it 225m AME > tapes I use - the EZ17 is itself reckoned to do up to a 1TB but > that's probably by spanning 7 tapes together! > >The other possibility I consider is: may the point of failure be > when the holding disk hits 35GB, do the 2GB chunks waiting to get > "held" clash with the 2GB chunks coming off onto the tape? Thats a possibility I think. But since amanda does a decent job of multithreading, sometimes a re-arrangement of the order of the disklist can fix it so taper has enough writes to tape to stay ahead of it for a while. For this, amstatus /config/ while amdump is runnnig, can when it works can be quite educational. My copy seems to have some syntax gotcha's in it ATM, latest 2.4.3b3 snapshot. (Yeah, I have a little spare blood :-) >One thing I would love to do is turn the hardware compression off. > However, while the "standalone" Mammoth 2 drive has this option > in its LCD driven menu, there is no option in the LCD menu of the > EZ17! Is there somewhere I can do this at software level on my > Solaris 7 Ultra 2 (st.conf?) Thats a Solaris system? I'd first verify that you are using a device thats non-compression since I'm told Solaris controls the hardware compression via the device selection. However, if there are options in the menu's, or even hidden dip-switches, I'd certainly try to force the issue to get it turned off and then let amanda do it because it can do it better if you have the cpu horsepower. One thing I've run into with my puny little DDS-2 tapes is that once the tape has been written to with the compression on, its abominably difficult to get its auto-detected compression turned back off. Part of the problem in running hardware compression is that different filetypes will compress less, or more, than average, with the end result being that amanda gets badly blind-sided regarding it view of how much a tape can hold. With hardware compression off, and amanda doing oh, lets say gzip at its highest compression ratio, then amanda can keep track of every byte that goes to the tape *after* compression, thereby giving it a good indication of how much it can schedule for a given tape, and then it won't try to stuff two pounds of worms back in that one pound container like it seems to be trying to do now. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 98.96+% setiathome rank, not too shabby for a hillbilly
