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
