PDA

View Full Version : Anyone using LTO4 in Solaris? Amtapetype fail



wsanders
September 8th, 2010, 07:24 AM
I have Zmanda 3.0.2 installed on a Solaris 10 host. The deafult install worked for a while but then started failing. I'm rerunning "amtapetype" to see if the drives have the right parameters (the params setup by ZEE don't seem to work very well.) The drives are HP LTO4.

When I run "amtapetype -o -e 800G -b 1024k -f /dev/rmt/0ubn", I get expected output for a while:

Applying heuristic check for compression.
Wrote random (uncompressible) data at 60490802.3606557 bytes/sec
Wrote fixed (compressible) data at 97103656.4210526 bytes/sec
Compression: enabled
Writing one file to fill the volume.
File 1, block 98011
...etc

But at the end the amtapetype fails with (which seems to be a known bug):

amtapetype: Wrote less than 1MB to the device: Error writing block: Mysterious s
hort write on tape device: Tried 1048576, got 0

And it writes

device_property "FSF_AFTER_FILEMARK" "false"

Which is contrary to the default for FSF_AFTER_FILEMARK, which is supposed to be True for Solaris and False for other OSes because it is a property of the driver, not the hardware.

Does anyone have an LTO4 on Solaris 10 set up and working? Could you post your Tapetype? It seems the FSF_AFTER_FILEMARK is critical to Amanda working correctly, if it is set wrong Amanda will not be able to find the right file on tape, which is exactly the reason why our backups seem to be no good anymore. The tapetype in the Zmanda wiki (below) is much more reasonable, but does not override the FSF_AFTER_FILEMARK property:

define tapetype HP-LTO4 {
comment "HP LTO4 800gb - SAS - Compression Off"
readblocksize 64 kbytes
length 772096 mbytes
filemark 0 kbytes
speed 71313 kps
}

My current tapetype (which is all wrong):

DEFINE TAPETYPE HP1 {
COMMENT ""
LBL_TEMPL ""
BLOCKSIZE 32
READBLOCKSIZE 32
LENGTH 1258291200
FILEMARK 1024
SPEED 200
FILE_PAD yes
}

But may be overwritten by (I am still threading through all the ZMC definitions):
DEFINE APPLICATION-TOOL app_amgtar {
COMMENT "ZMC GNUTAR Application Plugin: http://wiki.zmanda.com
/man/amgtar.8.html"
PLUGIN "amgtar"
PROPERTY "ONE-FILE-SYSTEM" "yes"
PROPERTY "ATIME-PRESERVE" "no"
PROPERTY "TAR-BLOCKSIZE" "2560"
PROPERTY "SPARSE" "yes"
PROPERTY "CHECK-DEVICE" "yes"
}

Thanks,

-w

dustin
September 19th, 2010, 08:46 PM
The "Mysterious short write on tape device: Tried 1048576, got 0" often means that your block size is larger than the actual on-tape block size. In this case, the tape drive breaks your blocks up into smaller tape blocks, and if it can only write *some* of those blocks, then it will get confused.

You might try upgrading to a newer version, where this and many other bugs are fixed.

wsanders
September 21st, 2010, 07:57 AM
I upgraded to 3.1.2 and amtapetype still prints 'device_property "FSF_AFTER_FILEMARK" "false"' at the beginning of the run. So I guess the Solaris driver behaves "normally" now?

I am just going to have to test this myself. Although it appears the most likely reason all our restores fail is because we do not have enough free disk space to hold an entire media's worth of backup chunks.

dustin
September 21st, 2010, 08:54 AM
The FSF_AFTER_FILEMARK property is determined experimentally, so I suspect that it's correct. I don't know much about Solaris, but perhaps there is some way that this can be configured there?

What does your failing restore look like?