slow tape drive - HP UX

This is a discussion on slow tape drive - HP UX ; I am reading the tape contents of /dev/rmt/0m with cpio. For some reason it's terribly slow, I am reading right now about 12Mb per hour. The extracted files do seem to be correct but why is it so terribly slow? ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: slow tape drive

  1. slow tape drive

    I am reading the tape contents of /dev/rmt/0m with cpio. For some
    reason it's terribly slow, I am reading right now about 12Mb per hour.
    The extracted files do seem to be correct but why is it so terribly
    slow?

    Config:
    HP-UX 11.11, tape is connected to a Ultra320 SCSI controller.
    The tape has not been written on this server but on another server
    (compatibility?).

    Any hint will be appreciated.

    Regards,

  2. Re: slow tape drive

    sparks wrote:
    > I am reading the tape contents of /dev/rmt/0m with cpio. For some
    > reason it's terribly slow, I am reading right now about 12Mb per hour.
    > The extracted files do seem to be correct but why is it so terribly
    > slow?
    >
    > Config:
    > HP-UX 11.11, tape is connected to a Ultra320 SCSI controller.
    > The tape has not been written on this server but on another server
    > (compatibility?).
    >
    > Any hint will be appreciated.
    >
    > Regards,


    What (*exact*) *type* of tape drive?

    In general: Default cpio record size is one 512-byte block, which is
    way, way too small for any streaming tape drive manufactured in the last
    couple of decades.

    You can make this better by writing the tape with the 5120-byte record
    option ('B'?) and even better by piping it to/from dd(1) with an even
    bigger record size.

    ftio(1) - which is an HP-UX-specific program - can also help, but it
    formally only 9-track reel-to-reel tapes, which are long, long gone out
    of fashion. Any other use is unsupported, so you're on your own.

    Better, generally, is to use fbackup(1M) and frecover(1M) with a big
    record size, but both fbackup(1M) and frecover(1M) *and* their tape
    format are HP-UX-specific, so you can't exchange with non-HP-UX systems.

  3. Re: slow tape drive

    sparks writes:

    > I am reading the tape contents of /dev/rmt/0m with cpio. For some
    > reason it's terribly slow, I am reading right now about 12Mb per hour.
    > The extracted files do seem to be correct but why is it so terribly
    > slow?


    Generally I'd suggest to LOOK and LISTEN: Does the tape move steadily, or does
    it "go, stop, reposition" again and again? Streaming of data is the secret for
    proper tape performance. Unfortunately HP-UX always seems to be slow for
    unknown reasons (Linux usually beats HP-UX in I/O performance, even when
    writing tapes)

    >
    > Config:
    > HP-UX 11.11, tape is connected to a Ultra320 SCSI controller.
    > The tape has not been written on this server but on another server
    > (compatibility?).
    >
    > Any hint will be appreciated.
    >
    > Regards,


  4. Re: slow tape drive

    On Jul 2, 7:00*am, Ulrich Windl
    wrote:
    > sparks writes:
    > > I am reading the tape contents of /dev/rmt/0m with cpio. For some
    > > reason it's terribly slow, I am reading right now about 12Mb per hour.
    > > The extracted files do seem to be correct but why is it so terribly
    > > slow?

    >
    > Generally I'd suggest to LOOK and LISTEN: Does the tape move steadily, ordoes
    > it "go, stop, reposition" again and again? Streaming of data is the secret for
    > proper tape performance. Unfortunately HP-UX always seems to be slow for
    > unknown reasons (Linux usually beats HP-UX in I/O performance, even when
    > writing tapes)
    >
    >
    >
    >
    >
    > > Config:
    > > HP-UX 11.11, tape is connected to a Ultra320 SCSI controller.
    > > The tape has not been written on this server but on another server
    > > (compatibility?).

    >
    > > Any hint will be appreciated.

    >
    > > Regards,- Hide quoted text -

    >
    > - Show quoted text -



    Have you been able to read tapes before at a faster rate?

    If "yes" is the tape known to be good? Any SCSI errors
    being logged? Dive been cleaned recently? Hardware
    compression 'on' by default on the drive?

    If "no" check any hardware settings, event logs and try
    another tape.

    Ken


+ Reply to Thread