Subject: Re: multi-volume dump fails, problem with st driver?
To: Scott Presnell <srp@zgi.com>
From: Matthew Jacob <mjacob@feral.com>
List: tech-kern
Date: 10/04/2002 10:33:20
On Fri, 4 Oct 2002, Scott Presnell wrote:
> It turns out I misunderstood the semantics for the no-rewind device.
> in using /dev/nrst0, the tape remained "mounted" and hence the driver
> didn't figure it out when I changed the tape. Using /dev/rst0 or
> using /dev/nrst0 + "mt offline" at the end of the first tape results
> in the correct behavior. man st(4) also helped clear it up.
>
> BTW, "mt eew" does nasty things to my tape drive: bad, short dump
> sessions, EOM reported after 10s of feet, etc. But I didn't try
> to follow up on that. After reading st(4) and the driver comments,
> perhaps "mt eew" should be disallowed for fixed blocksize drives?
Well, you're using a particularly stupid drive (sorry- no offense
intended). The 4000s have been known to have very limited f/w.
>
> Sorry for any confusion.
>
> - Scott
>
> Hauke Fath wrote:
> >
> > At 22:49 Uhr +0200 3.10.2002, Manuel Bouyer wrote:
> > >> Everything is fine until I insert the second tape: dump thinks it's already
> > >> at the EOT and aborts (but it's certainly not, since I just rewound it).
> > >
> > >Did you try 'mt eew' before dump ? I had to use this for multidumps on
> > >hexabyte ...
> >
> > I don't think it is 'early warning for EOM' he gets. His is a QIC drive...
> > QIC drives transparently write two filemarks at EOD, and st(4) doesn't play
> > nice with this habit.
> >
> > I had to hack st.c from NetBSD 1.3 to 1.5.x to get it to work with Tandberg
> > QIC drives - the issue bites Amanda, too. 1.6 appears to fix the issue, so
> > an upgrade would help here. Scott, if that is not an option, ask me for the
> > 1.5 patches.
> >
>