Jon:

>
>My environment is a bit smaller, a 1-way PIII with 0.5GB of memory :)
>But I have more holding disk than you (stick my tongue out ;)
>
>I have no problems with tape spanning when the holding disks
>are in use, and no situations that should call for them to not
>be used.
>
>But I decided to explore some limits.  So I turned off the holding
>disk by putting in "holdingdisk no" in the dumptype.  The results were
>basically, when my system tries to use mmap, I get errors if my
>tape_splitsize and/or fallback_splitsize are greater than 100MB.
>Even 128MB gives me "cannot allocate memory" errors in the mmap call.
>

Thanks very much for your response. Could you provide me with
some details on your OS type and version? I'm guessing Linux, but
I'd like to exclude Solaris x86 so that I'll know if this
is Solaris specific or not.

Since my first post, I've put a few debugging lines into the code
and determined that:

  - the first call to mmap returns an address that is
    tape_splitsize lower than the total 32-bit 4Gb address
    space
  - each successive call to mmap returns an address that
    is tape_splitsize lower than the previous one
  - mmap fails on the call that would result in all 4Gb of
    address space being used
    
It's almost as if the munmap call isn't working, but I've
also put in some code to detect its return status and it *says*
it's working fine :-)

So, if I use tape_splitsize=512Mb I can dump about 7DLEs, 1Gb
gives me 3 DLE's and 2Gb only allows 1 DLE.

I'm starting to lean towards this being a bug rather than something
I've messed up, particularly since:

  - the documentation suggests using large values for
    tape_splitsize (10% of tapesize)
  - I don't see how the mmap implementation could possibly
    work for tape_splitsize > 4Gb in a 32-bit executable
    (less if the OS was 32 bit and had to share the
    address space)
  - Amanda doesn't seem to compile properly as a 64-bit
    executable, so I don't think the developers were assuming
    a huge 64-bit address space
  
I'm going to cross-post this to amanda-hackers under your new
thread and then follow it there.

 
=================================================================
Sean Walmsley                 sean AT fpp.nuclearsafetysolutions DOT com
Nuclear Safety Solutions Ltd.  416-592-4608 (V)  416-592-5528 (F)
700 University Ave M/S H04 J19, Toronto, Ontario, M5G 1X6, CANADA