DDS-4 tape drive compatiblity - Ubuntu

This is a discussion on DDS-4 tape drive compatiblity - Ubuntu ; John F. Morse wrote: > Matt wrote: >> John F. Morse wrote: >>> [Crossposts removed and Followup set to a.o.l.u] >>> >>> Matt wrote: >> >>>> I find that each drive can read the tapes that it writes, but that ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 30 of 30

Thread: DDS-4 tape drive compatiblity

  1. Re: DDS-4 tape drive compatiblity

    John F. Morse wrote:
    > Matt wrote:
    >> John F. Morse wrote:
    >>> [Crossposts removed and Followup set to a.o.l.u]
    >>>
    >>> Matt wrote:

    >>
    >>>> I find that each drive can read the tapes that it writes, but that
    >>>> neither drive can read the tapes written by the other.

    >>
    >>> My suggestion is to leave well-enough alone since they are presently
    >>> working fine.

    >>
    >>
    >> I don't believe you've thought that through.
    >>

    >
    >
    > You are entitled to your beliefs, but you might want to explain why you
    > believe what you stated.



    Start with a proof that "they are presently working fine."

  2. Re: DDS-4 tape drive compatiblity

    Matt wrote:
    > John F. Morse wrote:
    >> Matt wrote:
    >>> John F. Morse wrote:
    >>>> [Crossposts removed and Followup set to a.o.l.u]
    >>>>
    >>>> Matt wrote:
    >>>
    >>>>> I find that each drive can read the tapes that it writes, but that
    >>>>> neither drive can read the tapes written by the other.
    >>>
    >>>> My suggestion is to leave well-enough alone since they are
    >>>> presently working fine.
    >>>
    >>>
    >>> I don't believe you've thought that through.
    >>>

    >>
    >>
    >> You are entitled to your beliefs, but you might want to explain why
    >> you believe what you stated.

    >
    > Start with a proof that "they are presently working fine."



    I cannot prove if your statement is the truth or a falsehood, Matt.

    Which statement? The one above, and reproduced here:

    "I find that each drive can read the tapes that it writes"

    You said it, not me. I didn't need to think it through because it is
    perfectly clear.


    --
    John

    No Microsoft, Apple, Intel, Novell, Trend Micro, nor Ford products were used in the preparation or transmission of this message.

    The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do. The GPL sounds like it was written by a human being, who wants me to know what I can do.

  3. Re: DDS-4 tape drive compatiblity

    Baron wrote:
    > Matt wrote:
    >> Baron wrote:
    >>> Matt wrote:
    >>>> John F. Morse wrote:
    >>>>
    >>>>> [Crossposts removed and Followup set to a.o.l.u]
    >>>>>

    .... snip ...
    >>
    >> Do you have experience using DDS-4 tape drives?

    >
    > Depends upon what you mean "experience" !


    'Matt' seems to have the ugly habit of installing 3-way crossposts
    in every response. I suggest just deleting them - no need to
    propagate them at all.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]:
    Try the download section.


    ** Posted from http://www.teranews.com **

  4. Re: DDS-4 tape drive compatiblity

    John F. Morse wrote:
    > Matt wrote:
    >> John F. Morse wrote:
    >>> Matt wrote:
    >>>> John F. Morse wrote:
    >>>>> [Crossposts removed and Followup set to a.o.l.u]
    >>>>>
    >>>>> Matt wrote:
    >>>>
    >>>>>> I find that each drive can read the tapes that it writes, but that
    >>>>>> neither drive can read the tapes written by the other.
    >>>>
    >>>>> My suggestion is to leave well-enough alone since they are
    >>>>> presently working fine.
    >>>>
    >>>>
    >>>> I don't believe you've thought that through.
    >>>>
    >>>
    >>>
    >>> You are entitled to your beliefs, but you might want to explain why
    >>> you believe what you stated.

    >>
    >> Start with a proof that "they are presently working fine."

    >
    >
    > I cannot prove if your statement is the truth or a falsehood, Matt.



    Right. You are supposed to show that my statement implies yours.


    > Which statement? The one above, and reproduced here:
    >
    > "I find that each drive can read the tapes that it writes"
    >
    > You said it, not me. I didn't need to think it through because it is
    > perfectly clear.


  5. Re: DDS-4 tape drive compatiblity

    In article <4KWXj.234$Vf.88@fe093.usenetserver.com>,
    Matt wrote:

    > Shouldn't these drives be able to read each other's tapes? Do I need to
    > adjust some parameters, or should I assume that at least one of them is
    > defective?


    In general, yes ... however even if you do everything correctly, it's
    still possible to produce tapes on one DDS drive that are not readable
    on another.

    I have had this issue in the past. I think the problem has to do with
    head alignment. I've heard of others having the same issue, so I don't
    think it's particularly uncommon. (In my case, I had two basically
    identical HP-12000s that would never read each other's tapes perfectly.)

    Anyway, it sounds like maybe there's an issue with the hardware
    compression also, but I just wanted to toss out there that even if you
    get everything else resolved, you still may not have perfect
    compatibility between devices.

    It's one of the reasons I finally gave up on DDS autoloaders and moved
    to HD-based backups.

    Good luck!
    -Kadin.

  6. Re: DDS-4 tape drive compatiblity

    Kadin2048 wrote:
    > In article <4KWXj.234$Vf.88@fe093.usenetserver.com>,
    > Matt wrote:
    >
    >> Shouldn't these drives be able to read each other's tapes? Do I need to
    >> adjust some parameters, or should I assume that at least one of them is
    >> defective?

    >
    > In general, yes ... however even if you do everything correctly, it's
    > still possible to produce tapes on one DDS drive that are not readable
    > on another.
    >
    > I have had this issue in the past. I think the problem has to do with
    > head alignment. I've heard of others having the same issue, so I don't
    > think it's particularly uncommon. (In my case, I had two basically
    > identical HP-12000s that would never read each other's tapes perfectly.)


    Head alignment used to be a problem with tape drives. And the greater the
    density written on the tapes, the greater the need for correct alignment.

    Ecrix designed a tape drive that worked somewhat differently from other tape
    drives, so alignment is much less critical. Ecrix was bought out by Exabyte
    who, in turn, has been bought out by Tandberg. I have two of their drives,
    one on each of my two computers. I can easily read tapes written on one and
    played on the other. This was not true with DDS-2 tapes that I frequently
    could not read even on the machine that write them. I also used some other
    tapes that used a floppy controller to run them (I think they were called
    Travan, or something like that). They were not too bad, but they were too
    slow and too small even then; I think I could get around a gigabyte on
    them). The DDS-2 were too small by todays standards; my RAM on my present
    computer could fill one of those when using compressed mode.
    >
    > Anyway, it sounds like maybe there's an issue with the hardware
    > compression also, but I just wanted to toss out there that even if you
    > get everything else resolved, you still may not have perfect
    > compatibility between devices.
    >
    > It's one of the reasons I finally gave up on DDS autoloaders and moved
    > to HD-based backups.


    I think it depends on your requirements whether disk or tape is the best for
    any individual. It is a trade-off, and YMWCV -- Your mileage will certainly
    vary.
    >
    > Good luck!
    > -Kadin.



    --
    .~. Jean-David Beyer Registered Linux User 85642.
    /V\ PGP-Key: 9A2FC99A Registered Machine 241939.
    /( )\ Shrewsbury, New Jersey http://counter.li.org
    ^^-^^ 15:55:01 up 4 days, 5:52, 4 users, load average: 4.31, 4.20, 4.11

  7. Re: DDS-4 tape drive compatiblity

    Matt wrote:
    > John F. Morse wrote:
    >> Matt wrote:
    >>> John F. Morse wrote:
    >>>> Matt wrote:
    >>>>> John F. Morse wrote:
    >>>>>> [Crossposts removed and Followup set to a.o.l.u]
    >>>>>>
    >>>>>> Matt wrote:
    >>>>>
    >>>>>>> I find that each drive can read the tapes that it writes, but
    >>>>>>> that neither drive can read the tapes written by the other.
    >>>>>
    >>>>>> My suggestion is to leave well-enough alone since they are
    >>>>>> presently working fine.
    >>>>>
    >>>>>
    >>>>> I don't believe you've thought that through.
    >>>>>
    >>>>
    >>>>
    >>>> You are entitled to your beliefs, but you might want to explain why
    >>>> you believe what you stated.
    >>>
    >>> Start with a proof that "they are presently working fine."

    >>
    >>
    >> I cannot prove if your statement is the truth or a falsehood, Matt.

    >
    >
    > Right. You are supposed to show that my statement implies yours.
    >
    >
    >> Which statement? The one above, and reproduced here:
    >>
    >> "I find that each drive can read the tapes that it writes"
    >>
    >> You said it, not me. I didn't need to think it through because it is
    >> perfectly clear.


    Your reply is useless, Matt. It makes absolutely no sense, and doesn't
    address the tape drive issue.

    If you want to play with words, I'm not interested.

    --
    John

    No Microsoft, Apple, Intel, Novell, Trend Micro, nor Ford products were used in the preparation or transmission of this message.

    The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do. The GPL sounds like it was written by a human being, who wants me to know what I can do.

  8. Re: DDS-4 tape drive compatiblity

    John F. Morse wrote:
    > Matt wrote:
    >> John F. Morse wrote:
    >>> Matt wrote:
    >>>> John F. Morse wrote:
    >>>>> Matt wrote:
    >>>>>> John F. Morse wrote:
    >>>>>>> [Crossposts removed and Followup set to a.o.l.u]
    >>>>>>>
    >>>>>>> Matt wrote:
    >>>>>>
    >>>>>>>> I find that each drive can read the tapes that it writes, but
    >>>>>>>> that neither drive can read the tapes written by the other.
    >>>>>>
    >>>>>>> My suggestion is to leave well-enough alone since they are
    >>>>>>> presently working fine.
    >>>>>>
    >>>>>>
    >>>>>> I don't believe you've thought that through.
    >>>>>>
    >>>>>
    >>>>>
    >>>>> You are entitled to your beliefs, but you might want to explain why
    >>>>> you believe what you stated.
    >>>>
    >>>> Start with a proof that "they are presently working fine."
    >>>
    >>>
    >>> I cannot prove if your statement is the truth or a falsehood, Matt.

    >>
    >>
    >> Right. You are supposed to show that my statement implies yours.
    >>
    >>
    >>> Which statement? The one above, and reproduced here:
    >>>
    >>> "I find that each drive can read the tapes that it writes"
    >>>
    >>> You said it, not me. I didn't need to think it through because it is
    >>> perfectly clear.

    >
    > Your reply is useless, Matt.



    Well, it did lead to a confirmation of my assessment of your mental
    capacity, so it was of some use to me, even if it didn't show anything
    new to most of the regulars.


    > It makes absolutely no sense,



    heh


    > and doesn't
    > address the tape drive issue.


    > If you want to play with words, I'm not interested.


  9. Re: DDS-4 tape drive compatiblity

    Matt writes:

    [snip]

    > Thanks to everybody for your help so far.
    >
    > I set DIP switches on the drive to disable compression.
    >
    > I find that the HP DDS Drives User Manual that I mention elsewhere on
    > the thread states that the DAT 40GB drive uses DCLZ compression. The
    > Sony docs for the Compaq drive say that too.
    >
    > I find that both drives can read each other's tapes, but I think it
    > was probably not fixed by turning off compression. It gets tedious to
    > experiment, as I shut down the system when I change drives, but I will
    > settle that question after a while.
    >
    > To fill in some details: Each drive reads its own tapes with ease. It
    > seems the HP can read and write about 1/3 faster than the Compaq. The
    > Compaq reads the HP's tapes pretty well, but the HP makes a lot of
    > awful noises as if doing some kind of head-loading or positioning
    > operation. I know these noises are normal for this drive, but they
    > shouldn't be so frequent. Pretty clearly it is retrying a failed
    > operation. In fact when I use du to look at what tar is writing on
    > the disk during extraction, I can see the output files fail to grow
    > while there is a lot of noise from the drive. It always succeeds
    > eventually, and the data comes out exactly correct each time---for
    > instance, I made the HP read and verify a tape of ten 100MB archives
    > made by the Compaq. But it takes the HP a lot of noise and something
    > like five times as much time to read the Compaq's tapes as it takes to
    > read its own tapes.


    What you are describing is probably not bad bits on the tape, but loss
    of streaming. DDS drives try to keep the tape moving even if another
    read request hasn't come in yet. If there is a big enough delay
    before the read request finally comes, then it will have to rewind the
    tape and try again.

    > Maybe it was the compression, but I also think it may have been that
    > the drives were dirty. I have used a cleaning tape on each one about
    > five times.
    >
    > Another change I made was to install the mt-st package, which
    > apparently has its own device drivers.


    Good! This package is highly useful. No, it doesn't have device
    drivers.

    > I also have been more patient. Rather than killing the job when the
    > drive makes so much noise, I am now virtually plugging my ears and
    > letting it run.
    >
    > I found this text at
    > http://grox.net/doc/linux/howto-OLD-...I-HOWTO-8.html
    >
    >
    >> Problems taking tapes to/from other systems
    >>
    >> You can't read a tape made with another operating system or another operating system can't read a tape written in Linux.
    >>
    >> Different systems often use different block sizes. On a tape device using a fixed blocksize, you will get errors when reading blocks written using a different block size.
    >>
    >> To read these tapes, you must set the blocksize of the tape driver to match the blocksize used when the tape was written, or to variable.
    >>
    >> NOTE : this is the hardware block size, not the blocking factor used with tar, dump, etc.
    >>
    >> You can do this with the mt command -
    >>
    >> mt setblk
    >>
    >> or
    >>
    >> mt setblk 0
    >>
    >> to get variable block length support.
    >>
    >> Note that these mt flags are NOT supported under the GNU version of mt which is included with some Linux distributions. Instead, you must use the BSD derived Linux SCSI mt command. Source should be available from
    >>
    >> tsx-11.mit.edu:/pub/linux/ALPHA/scsi
    >>
    >> Also note that by default, ST_BUFFER_BLOCKS (defined in /usr/src/linux/drivers/scsi/st_options.h in newer kernels, st.c in older kernels) is set to allow for a 32K maximum buffer size; you'll need to edit the source to use larger blocks.


    The above information you've quoted is old. The default maximum block
    size is still 32K, but with current 2.6 kernels, you can increase that
    by putting "options st buffer_kbs=nnn" in your /etc/modprobe.conf.
    (Replace the "nnn" with the number of K bytes you want.) It used to be
    that there was a limit of just under 128K, but I just tried loading
    the module with buffer_kbs set to 256, and it didn't complain. You
    can change the number, then "rmmod st" and "modprobe st" to reload the
    kernel module with a different buffer size--no need to reboot. Look
    at /var/log/messages to see what's happening when the module is
    loaded.

    > Here is the output of mt-st -f /dev/nst0 status:
    >
    > SCSI 2 tape drive:
    > File number=10, block number=0, partition=0.
    > Tape block size 0 bytes. Density code 0x26 (DDS-4 or QIC-4GB).
    > Soft error count since last status=0
    > General status bits on (81010000):
    > EOF ONLINE IM_REP_EN
    >
    > Can anybody offer any wisdom about changing the block size? I'm
    > thinking maybe the two drives are using two different block sizes and
    > that the Compaq firmware copes better with the difference than the HP
    > does.


    Notice that this tape drive is set to a block size of 0. That means
    the block size is variable. The size of the block will be determined
    by the size of the data buffer in the write call given by the
    application. If you are using tar, look at the "-b" option in its
    man page. This shows that with the default "-b 20" you should be
    getting 10K blocks. On reading, a block up to the size of the kernel
    module's buffer can be read and handed to the application. I don't
    know if a fixed block size will improve the read performance of your
    HP drive, but it's worth a shot. I would definitely increase the
    block size, allowing you to fit more data on the tape. I've used 32K
    in the past with DDS-3 drives, but you needn't feel constrained to
    that figure just because it's the default.

    If you want to use software compression, use bzip2 instead of gzip
    (tar's "-j" option instead of "-z"). The main reason is that bzip2
    can recover from a data error. If there is a data error in gzip'd
    data, you lose the rest of the tape file. Also, bzip2 compresses
    better. If you use software compression, you should also use tar's
    "--block-compress" option.

    Scott
    --
    Scott Hemphill hemphill@alumni.caltech.edu
    "This isn't flying. This is falling, with style." -- Buzz Lightyear

  10. Re: DDS-4 tape drive compatiblity

    Scott Hemphill wrote (in part):

    > What you are describing is probably not bad bits on the tape, but loss of
    > streaming. DDS drives try to keep the tape moving even if another read
    > request hasn't come in yet. If there is a big enough delay before the
    > read request finally comes, then it will have to rewind the tape and try
    > again.
    >

    This illustrates one of the advantages of VXA tape drives over DDS. The VXA
    drives are able to slow down the speed of the tape dynamically if the
    reading or writing process cannot keep up with the speed of the drive. So it
    is not necessary to stop the drive, reverse it, stop it, and then restart it
    when the speed of the computer and the speed of the drive do not match. This
    saves time, tape, noise, and trouble.

    You may not have the option of switching tape drives, but if you do, you may
    wish to examine these drives:

    http://www.exabyte.com/products/prod...pe.cfm?v=drive

    I use both VXA-1 and VXA-2 drives on SCSI controllers.

    The VXA-2 has twice the speed and capacity of a VXA-1.
    The VXA-320 has twice the speed and capacity of a VXA-2.

    --
    .~. Jean-David Beyer Registered Linux User 85642.
    /V\ PGP-Key: 9A2FC99A Registered Machine 241939.
    /( )\ Shrewsbury, New Jersey http://counter.li.org
    ^^-^^ 16:00:01 up 6 days, 5:57, 4 users, load average: 4.40, 4.41, 4.43

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2