On 2008-05-06 02:30, Nigel Allen wrote:
I'm experiencing an odd problem with a USB DAT drive that keeps running
out of space. Apologies for the length of the post.
The drive is supposed to be 36 / 72 GB.
Ok. The meaning of those numbers is:
- around 36 gigabytes (in powers of 1000 not in powers of 1024) space
to put the bytes on.
- in the optimistic premise that the internal compressor can achieve
a reduction by 2, you can feed 72 GB data, which will fit in the
36 GB raw space on the tape.
You must understand that the compression is an algorithm, just like
gzip or bzip2 (actually a less optimised version of the older "compress"
program). The tape drive does NOT double the capacity by writing
the bits in higher density, or with double number of tracks or so.
In real life this means that those tapes can hold about 33 Gibyte
(in base 2^10=1024). This is the number that Amanda needs.
See http://en.wikipedia.org/wiki/SI_prefix#Computing for the difference
between GB and GiB. (Amanda uses the MiB, GiB, but writes it as MB, GB, etc)
Then also realize that the compressor built into the those DAT drives
actually EXPANDS data that is not compressable by about 20%. (Contrary
to the compressor built into the more modern LTO drives, which do not do
that.)
When feeding the tape drive with already compressed data (you use bzip2
already), and you use hardware compression, then you loose again
tapespace.
Here's the kind of thing I see when I run a level 0 dump.
These dumps were to tape DailySet1-18.
*** A TAPE ERROR OCCURRED: [No more writable valid tape found].
[...]
taper: tape DailySet1-18 kb 31022240 fm 2 writing file: No space
left on device
driver: Taper error: "[writing file: No space left on device]"
The tape drive hit EOT after 1022240 KiB = 29.5 GiB.
Therefore I believe you have both hardware + software compression
enabled, resulting in a loss of about 3 GiB of space.
[...]
define tapetype HP-DAT72 {
comment "HP DAT72 USB with hardware compression on"
length 72 G
}
Especially when using software compression, use the native
capacity of the tape in the definition: Try with 34 GiB.
Or better, use "amtapetape -e 35g /dev/yourtapedrive" to get
an estimate (takes about 3-5 hours normally).
[...]
define dumptype custom-compress {
global
program "GNUTAR"
comment "Dump with custom client compression"
exclude list "/etc/amanda/exclude.gtar"
compress client custom
client_custom_compress "/usr/bin/bzip2"
}
When using bzip2, the hardware compressor can never compete with
that (except in speed). So better disable hardware compression.
mail.airsolutions.com.au mapper/VolGroup00-LogVol00
custom-compress
mail.airsolutions.com.au sda1 custom-compress
When using gnutar, why do you insist on specifying a device name.
Why not use the mount point itself. (Amanda will do the conversion
for you, but why make it so obscure.)
Any idea where I can start would be appreciated (apart from "bigger
tape" or "less data").
Another improvement is to break up the large dataset into
smaller ones, so that each one dump is much smaller than a the
capacity of your tape. That way, Amanda can better spread the dumps
over different tapes/days. See:
http://wiki.zmanda.com/index.php/How_To:Split_DLEs_With_Exclude_Lists
--
Paul Bijnens, xplanation Technology Services Tel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512
http://www.xplanation.com/ email: Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************
|
