On Fri, Jun 30, 2006 at 06:52:50AM -0400, Paul Graf wrote:
> >As Frank already noted, you are taping direct to tape,
> >not using your defined holding disk.
> >
> >>
> >> holdingdisk hd1 {
> >> comment "main holding disk"
> >> directory "/tmp/amandahld" # where the holding disk is
> >> use 20000 Mb # how much space can we use on it
> >> chunksize 1Gb # size of chunk if you want big dump to be
> >> }
> >>
> >
> >Is your /tmp directory (file system) large enough to support a
> >20GB holding disk and all the other uses you might have for it?
>
> Yup, I could definitely devote more space to the holding disk, or make
> multiple holding disks.
>
> >> # dumptypes
> >>
> >> define dumptype global {
> >> comment "Global definitions"
> >> tape_splitsize 20000 mbytes
> >> split_diskbuffer "/tmp/amandasplit/split"
> >> index yes
> >> holdingdisk yes
> >> }
> >
> >You really do like /tmp don't you?
> >
According to the notes below this directory did not exist.
You will have to create it for it to be used.
What about the holding disk, does it exist?
> OK, will try tweaking the holding space for the backup this weekend.
Not holding disk only, unless you make it big enough,
but the split_diskbuffer in particular.
> Also, here's an interesting part of the email that amanda sent out after
> the backup. Notice the over 100% usage on some of the tapes, and I'm not
> using compression...
A guess, your tapetype specifies the "native" size, say 200GB for an LTO2.
If you run the drive with hardware compression turned on, then you are
still getting compression.
>
> STATISTICS:
> Total Full Incr.
> -------- -------- --------
> Estimate Time (hrs:min) 0:13
...
>
>
> NOTES:
> planner: Adding new disk www.int:/raid01.
> taper: mkstemp/open of
> /tmp/amandasplit/split/splitdump_buffer_erZtRnfailed (No such file or
> directory): using fallback split size of 10240kb to buffer
> www.int:/raid01.0 in-memory
> taper: mkstemp/open of
> /tmp/amandasplit/split/splitdump_buffer_VUSXQefailed (No such file or
> directory): using fallback split size of 10240kb to buffer
> files.int:/raid01/PUBLIC.0 in-memory
See, here the disk buffer directories do not exist, so the tape
spanning falls back to using memory buffers of 10MB. That is the
default and can also be configured. But note below the result ...
> taper: tape 000213 kb 283015264 fm 27618 writing file: Input/output error
Here is the report of a tape full. It wrote lots of KiloBytes (kb 283...)
and more importantly, tons of tiny files "fm 27618". Most would be the
10MB buffers from above. The others might be some of your other DLE's.
This could certainly slow things down. I think that most drives stop
after writing an end of tape file "filemark (fm)". Then for writing
the next tape file they reverse the tape a bit, and start it moving
forward again so the tape is up to speed when it crosses the filemark.
> taper: continuing files.int:/raid01/PUBLIC.0 on new tape from 161239040kb
> mark: [writing file: Input/output error]
Start of the next tape.
> taper: tape 000214 kb 283146272 fm 27652 writing file: Input/output error
Again reached end of a tape in the middle of a file, this time even more
tiny files.
> taper: continuing files.int:/raid01/PUBLIC.0 on new tape from 444385280kb
> mark: [writing file: Input/output error]
> taper: tape 000221 kb 231352352 fm 22594 writing file: Input/output error
> taper: continuing files.int:/raid01/PUBLIC.0 on new tape from 675737600kb
> mark: [writing file: Input/output error]
> taper: tape 000227 kb 86104032 fm 8409 [OK]
So, to write that one DLE took over 80000 10MB files, each one stopping
the tape, reversing, starting again. Had the split_diskbuffer existed
so it could use the 20GB tape file size you requested, that would have
dropped to about 40 stops and starts.
--
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)
|
