On Tue, Aug 30, 2005 at 01:08:32PM -0400, Jon LaBadie enlightened us:
> Have there been major changes/bug fixes to the taper
> algorithm "largestfit" in recent versions?  I'm running
> 2.4.4, but it is a two year old snapshot and I'm seeing
> some really strange behavior.
> 
> I gave up on getting my tape drive repaired and tore it
> apart myself.  Did not really do anything significant,
> though I did try to lubricate the sticking surfaces.
> I tried some spray on teflon then the white lithium
> that someone suggested (tnx).  The mechanism still seems
> very tight but when I reassembled it, the changer works.
> How long it will, who knows.
> 
> 
> So now I've got lots of dump's to amflush.  Hate to tell you
> how old they are but the drive is playing "Jingle Bells". ;)
> 
> Couple of notes about the setup, 4 separate holding disks,
> only 3 have any dumps.  The full holding disks were impacting
> other things so I deleted all but the last two level 0's
> and the last level 1.  That gave me 35 dumps to flush ranging
> in size from 6300MB to < 1MB.
> 
> My drive is DDS-3, my tapetype lists it at 11700MB capacity.
> Todays first amflush report shows it failing at just over
> 12000MB for each of the first 3 tapes.
> 
> The strange observations.
> 
> - first dump it picked to tape was not the largest,
>   but the 3rd largest at 5500MB
> - second dump it picked was the 28th largest at 8MB
> - then back to a big one, 8th largest at 2500MB
> - two more files were taped bringing the total taped to
>   8900MB, leaving about 2700MB of claimed capacity
> - but now this line appears in the amflush log:
> 
>     driver: startaflush: Using first because nothing fit
> 
>   and sure enough, it tries to tape the largest, 6300MB
>   dump rather than picking one of the 20 or so other dumps
>   that would have fit.
> 
> Similar things happened on the 2nd and 3rd tapes (my runtape
> setting is 3).  On the second tape, it retried the largest
> dump, then five more until 9300MB were taped.  The log
> again claims "Using first because nothing fit" but picks
> not the largest available (5800MB), but a 5100MB dump.
> 
> That of course failed and was put first on the 3rd tape.
> A 4900MB dump was added and at 9000MB full it again
> chose a too large dump with many available that would
> fit.
> 
> The second largest dump still has not been taped.
> 
> 
> If this is a known and fixed problem my apologies
> for a long-winded explanation.  Otherwise, any
> thoughts as to why the wierdness?
> 

In the 2.4.5 line, dumper will now try smallest instead of first if nothing
will fit, in hopes that the smallest thing just might fit to tape. As to why
it wasn't picking the largest to begin with is beyond me.

Matt


-- 
Matt Hyclak
Department of Mathematics 
Department of Social Work
Ohio University
(740) 593-1263