Definite progress.  Dump completed OK so it looks like that patch does the 
trick.  However ... 

Taping of the dump started and ran to end of the first tape.  Then changed to 
next tape and started taping the dump again from the start (and failed when it 
ran out of tape) - extract from log at end.  That isn't what I was expecting - 
I thought that 2.5.x allowed for spanning dumps over tapes.

Is there anything I need to add to the config to make this happen - I think 
I've been through the relevant bits of the docs and didn't spot anything.  A 
_very_ quick scan of taper.c seemed to indicate that this should just work (and 
I'm just checked that the system is using the 2.5.0 taper - start of amdump log 
says ...
  taper: pid 17514 executable taper version 2.5.0)

Paul

> -----Original Message-----
> From: Paul Haldane 
> 
> Jean-Louis Martineau said:
> 
> > Are you on a machine where a LONG is 4 bytes in size?
> 
> Yup
> 
> > Then it's an overflow, could you try the attached patch.
> 
> Thanks - patch applied, backup running, I'll let you know how 
> it went tomorrow.
> 
> Paul
> 
> > Paul Haldane wrote:
> > > I've just installed 2.5.0 on one of our backup servers 
> > (output from amadmin <config> version at end) and have some 
> > odd behaviour to do with holding disks (at least I think 
> > that's the problem).
> > >
> > > We've been running Amanda (using the standard Fedora Core 2 
> > rpms -amanda-2.4.4p2-3) for ages - no problems.  We're keen 
> > to move to 2.5.0 as I understand that gives us the ability to 
> > span tapes when doing backups.  Clients will still be running 
> > 2.4.x (FC3 with amanda-client-2.4.4p3-1 in the case of the 
> > client I'm having this particular problem with).
> > >
> > > We've got six holding disks (which are all recognised by 
> > amcheck and were correctly used with 2.4.4).
> > >
> > > When the backup ran last night the smaller DLEs went 
> > through fine and were taped but we have one DLE which is 
> > (just) bigger than a tape and bigger than a single holding 
> > disk (~ 223G - largest of the successfully tapes DLEs was 37G).
> > >  
> > > It seems that Amanda filled one holding disk, moved on to a 
> > second holding disk, used some space there and then gave up 
> > when nearly at the end of the dump apparently thinking that 
> > it had run out of holding space (but the current holding area 
> > was only 74% full).  I think I've pulled the relevant lines 
> > out of the log below (but have attached the last 50 lines in 
> > case I'm wrong or have message up the formatting).
> > >
> > > Any thoughts on what might be happening?  Is Amanda 
> > thinking that it's out of holding space or have I 
> > misinterpreted the messages?  Are there any of the options 
> > that I used to build the Amanda server with which might be 
> > problematical?
> > >
> > > Paul

taper: r: switching to next holding chunk 
'/disk/1/amanda/ISS1/20060403155612/logproc._store_proxylogs.0.61'
taper: r: switching to next holding chunk 
'/disk/1/amanda/ISS1/20060403155612/logproc._store_proxylogs.0.62'
taper: writing end marker. [AM1249 ERR kb 220910080 fm 9]

changer: opening pipe to: /usr/lib/amanda/chg-zd-mtx -info
changer: got exit: 0 str: 49 58 1 1
changer_query: changer return was 58 1 1
...
changer: opening pipe to: /usr/lib/amanda/chg-zd-mtx -search AM1250
changer: got exit: 0 str: 50 /dev/nst0
taper: wrote label `AM1250' date `20060403'

driver: state time 33708.239 free kps: 91400 space: 471281288 taper: writing 
idle-dumpers: 6 qlen tapeq: 0 runq: 0 roomq:
 0 wakeup: 0 driver-idle: no-dumpers

driver: hdisk-state time 33708.239 hdisk 0: free 133920752 dumpers 0 hdisk 1: 
free 34612484 dumpers 0 hdisk 2: free 34906
564 dumpers 0 hdisk 3: free 133920744 dumpers 0 hdisk 4: free 0 dumpers 0 hdisk 
5: free 133920744 dumpers 0
driver: result time 33708.239 from taper: TRY-AGAIN 00-00018 [writing file: No 
space left on device]

driver: taper-tryagain time 33708.239 disk logproc:/store/proxylogs

driver: send-cmd time 33708.239 to taper: FILE-WRITE 00-00019 
/disk/1/amanda/ISS1/20060403155612/logproc._store_proxylogs
.0 logproc fffffeff9ffe0f0000 /store/proxylogs 0 20060403 0
driver: startaflush: FIRST logproc /store/proxylogs 233098364 307200000
taper: r: switching to next holding chunk 
'/disk/1/amanda/ISS1/20060403155612/logproc._store_proxylogs.0.1'
taper: r: switching to next holding chunk 
'/disk/1/amanda/ISS1/20060403155612/logproc._store_proxylogs.0.2'