Re: taperalgo largestfit can cause "too many taper retries"
Sven Rudolph wrote: Some approaches: a) increase the "too many taper retries" limit (or make it configurable): ... b) avoid this by never trying to write anything when a tape is full ... c) don't count taper retries that happen after the tape is full (according to tapetype entry) d) make it only fatal when this DLE is the first (only) on tape. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
taperalgo largestfit can cause "too many taper retries"
I'm having a problem which seems to be caused by a changed taping order. >From the log file (grepped): DISK planner foo /data SUCCESS dumper foo /data 20030615 0 [sec 10713.506 kb 16686543 kps 1557.5 orig-kb 22953940] INFO taper retrying foo:/data.0 on new tape: [writing file: No space left on device] INFO taper retrying foo:/data.0 on new tape: [writing file: No space left on device] FAIL driver foo /data 0 20030615 [too many taper retries] The taping is tried two times, and then it failed immediately after the second try. The "too many" limit seems to be hardcoded as "try twice". There were no tape media errors, instead the DLE simply hit the tape end. This problem happens with "taperalgo largestfit". When the end-of-tape is hit a new tape is inserted and the taperalgo selects the best-fitting DLE. This usually isn't the DLE that got the EOF (contrary to pre-taperalgo times, where the same DLE was taped again). So the original DLE will be tried some time later; and this could mean it will hit end-of-tape again. Then this DLE will be failed. Some approaches: a) increase the "too many taper retries" limit (or make it configurable): In cases when it is really impossible to tape a given DLE more tape and time will be wasted. In addition it is difficult to find a sensible value. b) avoid this by never trying to write anything when a tape is full (according to tapetype entry): The things described by Eric Siegerman in <[EMAIL PROTECTED]> would help here; using newtape as secondchance will be safe; and secondchance smallest would make the problem more unlikely (my guess). c) don't count taper retries that happen after the tape is full (according to tapetype entry) I have no real preference, c) might be the easiest to implement but b) might be a good idea anyway. It is a somewhat stochastical problem, but I expect that other people will run in this too. Sven
Re: Too many taper retries
On Friday 13 September 2002 02:37, Mozzi wrote: >Gene Heskett wrote: >> On Tuesday 28 April 2020 05:33, Gene Heskett wrote: >> >> I just noted that my clock was foobar, set for something in >> april 2020! As I have a daily rdate, is there any way to >> ascertain that the rdate request to the server returns a sane >> result before it blindly resets everything? It happened >> yesterday morning on cron executing my setibatch -uploads script >> which includes this rdate command as it finishes up. >> >> Sort of embarrasing that I missed it for nearly 2 days. > >rdate -p ---> outputs the result to screen >rdate -s ---> sets the time > >Mozzi Uh huh, and it was rdate that messed it up in the first place, apparently accepting garbage for a bad reply. The last log entry with the right time was about 5 minutes before a cron script servicing my setiathome cache finished up by running rdate to set the time. I haven't yet changed the script, and its worked properly the last 2 times, and will be executed again in about 12 minutes. One of the reasons I'm sitting here at this time of the morning. :-( -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.15% setiathome rank, not too shabby for a WV hillbilly
Re: Too many taper retries
Gene Heskett wrote: > On Tuesday 28 April 2020 05:33, Gene Heskett wrote: > > I just noted that my clock was foobar, set for something in april > 2020! As I have a daily rdate, is there any way to ascertain that > the rdate request to the server returns a sane result before it > blindly resets everything? It happened yesterday morning on cron > executing my setibatch -uploads script which includes this rdate > command as it finishes up. > > Sort of embarrasing that I missed it for nearly 2 days. > rdate -p ---> outputs the result to screen rdate -s ---> sets the time Mozzi
Re: Too many taper retries
On Tuesday 28 April 2020 05:33, Gene Heskett wrote: I just noted that my clock was foobar, set for something in april 2020! As I have a daily rdate, is there any way to ascertain that the rdate request to the server returns a sane result before it blindly resets everything? It happened yesterday morning on cron executing my setibatch -uploads script which includes this rdate command as it finishes up. Sort of embarrasing that I missed it for nearly 2 days. >On Wednesday 11 September 2002 23:03, Alvin Ko wrote: >>I used amanda 2.4.2p2 with a DDS-3 tape drive to do a full backup >> of my Linux last night. In the amanda.conf file, I used >> chg-manual as the changer with 3 tapes. My /export/home folder >> has 23GB data. I had labeled three tapes (Tape-01, Tape-02, >> Tape-03) and then start the backup. 3 hours later, she asked me >> to insert backup tape into slot 1. When amdump completed, I got >> the following report. >>--- >>These dumps were to tapes Tape-01, Tape-02, Tape-03. >>The next 3 tapes Amanda expects to used are: a new tape, a new >> tape, a new tape. >> >>FAILURE AND STRANGE DUMP SUMMARY: >> localhost /export/home lev 0 FAILED [too many taper retries] >>... >>NOTES: >> planner: Adding new disk localhost:/boot. >> planner: Adding new disk localhost:/usr. >> planner: Adding new disk localhost:/. >> planner: Adding new disk localhost:/export/home. >> planner: Adding new disk localhost:/home. >> planner: Adding new disk localhost:/var. >> planner: Adding new disk localhost:/opt. >> taper: tape Tape-01 kb 12013824 fm 7 writing file: No space >> left on device taper: retrying localhost:/export/home.0 on new >> tape: [writing file: No space left on device] >> taper: tape Tape-02 kb 12004832 fm 1 writing file: No space >> left on device taper: retrying localhost:/export/home.0 on new >> tape: [writing file: No space left on device] >> taper: tape Tape-03 kb 0 fm 0 [OK] >> driver: Could not rmdir /mnt/hdc1/20020911: Directory not empty >>--- >>She could not backup my /export/home folder into multiple tapes. >> Anybody knows why? >> >>Best Regards, >> >>Alvin K. T. Ko > >How big is /export/home? If its bigger than your DDS3 tape, you >will have to break that entry up into even smaller pieces. > >Basicly, amanda cannot span more than one tape with a single >filesystem, and probably never will. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.15% setiathome rank, not too shabby for a WV hillbilly
Re: Too many taper retries
--On Thursday, September 12, 2002 11:03:48 +0800 Alvin Ko <[EMAIL PROTECTED]> wrote: > I used amanda 2.4.2p2 with a DDS-3 tape drive to do a full backup of my > Linux last night. In the amanda.conf file, I used chg-manual as the changer > with 3 tapes. My /export/home folder has 23GB data. I had labeled three > tapes (Tape-01, Tape-02, Tape-03) and then start the backup. 3 hours later, > she asked me to insert backup tape into slot 1. When amdump completed, I got > the following report. > --- > These dumps were to tapes Tape-01, Tape-02, Tape-03. > The next 3 tapes Amanda expects to used are: a new tape, a new tape, a new > tape. > > FAILURE AND STRANGE DUMP SUMMARY: > localhost /export/home lev 0 FAILED [too many taper retries] > ... > NOTES: > ... > taper: tape Tape-01 kb 12013824 fm 7 writing file: No space left on device > taper: retrying localhost:/export/home.0 on new tape: [writing file: No > space left on device] > taper: tape Tape-02 kb 12004832 fm 1 writing file: No space left on device > taper: retrying localhost:/export/home.0 on new tape: [writing file: No > space left on device] > taper: tape Tape-03 kb 0 fm 0 [OK] > driver: Could not rmdir /mnt/hdc1/20020911: Directory not empty > --- > She could not backup my /export/home folder into multiple tapes. Anybody > knows why? > > Best Regards, > > Alvin K. T. Ko Amanda can not backup any filesystem that is bigger than a single tape. Evidently your tapetype has a size listed greater than the actual capacity of your tape or Amanda wouldn't even have tried. You mentioned DDS3 which has a 12GB raw capacity, and that is about how much taper says it wrote before getting the 'no space' error. If your data is highly compressible, you might be able to get it to fit using compression, otherwise you will have to split your disklist entry for /export/home into a few (or several) subdirectories that will each fit on a tape and use tar to do the backups (dump usually either won't back up subdirectories or will be unable to keep track of the dumpdates for them). Frank -- Frank Smith[EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: Too many taper retries
On Wednesday 11 September 2002 23:03, Alvin Ko wrote: >I used amanda 2.4.2p2 with a DDS-3 tape drive to do a full backup > of my Linux last night. In the amanda.conf file, I used > chg-manual as the changer with 3 tapes. My /export/home folder > has 23GB data. I had labeled three tapes (Tape-01, Tape-02, > Tape-03) and then start the backup. 3 hours later, she asked me > to insert backup tape into slot 1. When amdump completed, I got > the following report. >--- >These dumps were to tapes Tape-01, Tape-02, Tape-03. >The next 3 tapes Amanda expects to used are: a new tape, a new > tape, a new tape. > >FAILURE AND STRANGE DUMP SUMMARY: > localhost /export/home lev 0 FAILED [too many taper retries] >... >NOTES: > planner: Adding new disk localhost:/boot. > planner: Adding new disk localhost:/usr. > planner: Adding new disk localhost:/. > planner: Adding new disk localhost:/export/home. > planner: Adding new disk localhost:/home. > planner: Adding new disk localhost:/var. > planner: Adding new disk localhost:/opt. > taper: tape Tape-01 kb 12013824 fm 7 writing file: No space left > on device taper: retrying localhost:/export/home.0 on new tape: > [writing file: No space left on device] > taper: tape Tape-02 kb 12004832 fm 1 writing file: No space left > on device taper: retrying localhost:/export/home.0 on new tape: > [writing file: No space left on device] > taper: tape Tape-03 kb 0 fm 0 [OK] > driver: Could not rmdir /mnt/hdc1/20020911: Directory not empty >--- >She could not backup my /export/home folder into multiple tapes. > Anybody knows why? > >Best Regards, > >Alvin K. T. Ko How big is /export/home? If its bigger than your DDS3 tape, you will have to break that entry up into even smaller pieces. Basicly, amanda cannot span more than one tape with a single filesystem, and probably never will. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.15% setiathome rank, not too shabby for a WV hillbilly
Too many taper retries
I used amanda 2.4.2p2 with a DDS-3 tape drive to do a full backup of my Linux last night. In the amanda.conf file, I used chg-manual as the changer with 3 tapes. My /export/home folder has 23GB data. I had labeled three tapes (Tape-01, Tape-02, Tape-03) and then start the backup. 3 hours later, she asked me to insert backup tape into slot 1. When amdump completed, I got the following report. --- These dumps were to tapes Tape-01, Tape-02, Tape-03. The next 3 tapes Amanda expects to used are: a new tape, a new tape, a new tape. FAILURE AND STRANGE DUMP SUMMARY: localhost /export/home lev 0 FAILED [too many taper retries] ... NOTES: planner: Adding new disk localhost:/boot. planner: Adding new disk localhost:/usr. planner: Adding new disk localhost:/. planner: Adding new disk localhost:/export/home. planner: Adding new disk localhost:/home. planner: Adding new disk localhost:/var. planner: Adding new disk localhost:/opt. taper: tape Tape-01 kb 12013824 fm 7 writing file: No space left on device taper: retrying localhost:/export/home.0 on new tape: [writing file: No space left on device] taper: tape Tape-02 kb 12004832 fm 1 writing file: No space left on device taper: retrying localhost:/export/home.0 on new tape: [writing file: No space left on device] taper: tape Tape-03 kb 0 fm 0 [OK] driver: Could not rmdir /mnt/hdc1/20020911: Directory not empty --- She could not backup my /export/home folder into multiple tapes. Anybody knows why? Best Regards, Alvin K. T. Ko
"too many taper retries"
On the other hand, amflush seems to be complain that the dump image is too big. ??? INFO taper tape library-DH3821 kb 30969792 fm 1 writing file: short write START taper datestamp 20020502 label library-DH3822 tape 1 INFO taper retrying diglib1:/AMNH/congo/SERVICE/photos/4x5a.0 on new tape: [writing file: short write] INFO taper tape library-DH3822 kb 30979776 fm 1 writing file: short write START taper datestamp 20020502 label library-DH3823 tape 2 INFO taper retrying diglib1:/AMNH/congo/SERVICE/photos/4x5a.0 on new tape: [writing file: short write] WARNING amflush /amanda-holding/d5/20020430/diglib1._AMNH_congo_SERVICE_photos_4x5a.0: too many taper retries, leaving file on disk WARNING amflush Could not rmdir /amanda-holding/d5/20020430. Check for cruft. I'm using DLT IV tapes in a DLT7000 drive. Some light, anyone? -fil -- fil krohnengold systems administrator - IT american museum of natural history [EMAIL PROTECTED]
"too many taper retries"
[amanda 2.4.2p2 on solaris 2.6]
Howdy -
I've been handed a bunch (11) of < 35G file systems that I
need to start backing up. I have two 15xDLT changers with two
drives in each at my disposal. The file systems contain a lot of
comressed data so I'm not using compression - just ufsdump.
[chg-scsi, chagerdev is /dev/rsst6, (tape)dev is /dev/rmt/8n]
And I'm trying to get an initial set of fulls on tape before I
start a regular cycle - using:
define dumptype library-dump {
nocomp-root
comment "for the library - full only - just for now"
strategy noinc
record no
}
Problem: the two largest dump images are never making it onto
tape though they are smaller than the media. There's plenty of
tape available. I'm using 14 runtapes, 7 days, one run per
cycle. The estimates are:
32247843K
32023555K
30507206K
28295773K
27471564K
25219602K
13415685K
13033377K
11460787K
10568289K
10084276K
8498213K
As far as I can tell, amanda is trying to fit as many images onto
each tape as possible, but in the process it's hitting a limmit
and leaving images on disk despite four available tapes waiting
for data in the configuration.
Is it possible for me to assure amanda that it should just keep
trying and that there's plenty of tape available for what it's
trying to do? Perhaps milk and cookies?
-fil
--
fil krohnengold
systems administrator - IT
american museum of natural history
[EMAIL PROTECTED]
