Results 1 to 4 of 4

Thread: Anyone using LTO4 in Solaris? Amtapetype fail

  1. #1
    Join Date
    Nov 2009
    Posts
    21

    Default Anyone using LTO4 in Solaris? Amtapetype fail

    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: [url]http://wiki.zmanda.com[/url]
    /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

  2. #2
    Join Date
    Mar 2007
    Location
    Chicago, IL
    Posts
    688

    Default

    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.

  3. #3
    Join Date
    Nov 2009
    Posts
    21

    Default "FSF_AFTER_FILEMARK" still false in 3.1.2

    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.

  4. #4
    Join Date
    Mar 2007
    Location
    Chicago, IL
    Posts
    688

    Default

    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •