I upgraded to 2.4.5 with the new "revert back to smallest instead of first"
logic when nothing will fit. It seems to work as expected with one
exception.
I had about 120GB of data to flush to my 100GB LTO1 tape. When I got the
report after amflush had finished, it had only taped about 96GB. Odd, I
thought, so I looked at the log:
----------------------------------------------------------------------------
driver: startaflush: Using SMALLEST because nothing fit
driver: send-cmd time 8262.816 to taper: FILE-WRITE 00-00111
/dumps/Dailies/20050503/bing.math.ohiou.edu._smbexport.0 bing.math.ohiou.edu
UNKNOWNFEATURE /smbexport 0 20050503
driver: startaflush: LARGESTFIT bing.math.ohiou.edu /smbexport 11759460
4134256
driver: state time 8262.816 free kps: 1414400 space: 99675036 taper: writing
idle-dumpers: 6 qlen tapeq: 29 runq: 0 roomq: 0 wakeup: 86400 driver-idle:
not-idle
driver: interface-state time 8262.816 if : free 14400 if ETH0: free 400000
if LOCAL: free 1000000
driver: hdisk-state time 8262.816 hdisk 0: free 99675036 dumpers 0
taper: writing end marker. [Dailies10 ERR kb 104225216 fm 111]
driver: result time 8612.513 from taper: TAPE-ERROR 00-00111 [writing file:
No space left on device]
driver: finished-cmd time 8612.513 taper wrote bing.math.ohiou.edu:/smbexport
-----------------------------------------------------------------------------
It decided that an 11GB dump was the smallest that would fit only because
it's the only one from 20050503, even though there are much smaller dumps
that are from the 4th and 5th.
Would it make sense in this case to skip over the oldest by date when
nothing else would fit? It would seem to make sense to me since I would have
another 4GB of data or so on the tape, and that much more room on my holding
disk. Perhaps a configuration variable "ignoreoldestwontfit" or something
more understandable would be good.
Thoughts?
Matt
--
Matt Hyclak
Department of Mathematics
Department of Social Work
Ohio University
(740) 593-1263
pgpBTOuJ6kxrC.pgp
Description: PGP signature
|
