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?

jl
-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)