Re: Busted Tape Drive

2008-08-07 Thread Dustin J. Mitchell
This all sounds great.  Not to sound like an overworked developer, but
could you all please update the FAQ entry accordingly? ;)

  
http://wiki.zmanda.com/index.php/FAQ:Why_can_I_write_new_labels_to_my_tapes_but_can%27t_read_the_old_ones%3F

Dustin

-- 
Storage Software Engineer
http://www.zmanda.com


Re: Busted Tape Drive

2008-08-07 Thread Matthew Marlowe

 For example, in your rc.conf
file you may have:

/bin/mt -f /dev/nst0 defcompression 0
/bin/mt -f /dev/nst0 defblksize 0



I think this probably gets too specific.

The error could just as easily occur because amanda is upgraded to new 
binaries which are not compiled for the proper blocksize at the same 
time that a new amanda configuration file is missing a blocksize option.


We should probably just expand the blocksize section of the FAQ and 
point people with issues reading tape labels to it as a possible cause.
I know the whole concept of fixed blocksize verse variable can get 
confusing.


I know we put "options st buffer_kbs=256" in /etc/modprobe.conf here to 
force a 256K fixed blocksize rather than deal with variable size.


--
DeployLinux Consulting, Inc
Senior Infrastructure Consultant
Tel: 805-857-9144  [EMAIL PROTECTED]
Yahoo IM: deploylinuxconsulting



Re: Busted Tape Drive

2008-08-07 Thread Steven Backus
Dustin J. Mitchell" <[EMAIL PROTECTED]> writes:

> Are there more details to add?  The 'mt' invocations in rc.conf may be
> helpful to others, for example.

FAQ:Why can I write new labels to my tapes but can't read the old ones?

Check your blocksize.  This behavior occurs when the tape unit is
set to have a particular block size (that may not match at read
time what was used to write a tape).  For example, in your rc.conf
file you may have:

/bin/mt -f /dev/nst0 defcompression 0
/bin/mt -f /dev/nst0 defblksize 0

and you should verify these commands are working correctly.

Steve
-- 
Steven J. BackusComputer Specialist
University of Utah  E-Mail:  [EMAIL PROTECTED]
Genetic EpidemiologyAlternate:  [EMAIL PROTECTED]
391 Chipeta Way -- Suite D  Office:  801.587.9308
Salt Lake City, UT 84108-1266   http://www.math.utah.edu/~backus


Re: Busted Tape Drive

2008-08-07 Thread Steven Backus
"Dustin J. Mitchell" <[EMAIL PROTECTED]> writes:

> I haven't followed this too closely, but are there some takeaway
> messages that could be worked into a FAQ here?
>   http://wiki.zmanda.com/index.php/FAQ

FAQ:Why can I write new labels to my tapes but can't read the old ones?

Check your blocksize.  This behavior occurs when the tape unit is
set to have a particular block size (that may not match at read
time what was used to write a tape).

Steve
-- 
Steven J. BackusComputer Specialist
University of Utah  E-Mail:  [EMAIL PROTECTED]
Genetic EpidemiologyAlternate:  [EMAIL PROTECTED]
391 Chipeta Way -- Suite D  Office:  801.587.9308
Salt Lake City, UT 84108-1266   http://www.math.utah.edu/~backus


Re: Busted Tape Drive

2008-08-07 Thread Dustin J. Mitchell
On Thu, Aug 7, 2008 at 5:25 PM, Steven Backus
<[EMAIL PROTECTED]> wrote:
> FAQ:Why can I write new labels to my tapes but can't read the old ones?
>
> Check your blocksize.  This behavior occurs when the tape unit is
> set to have a particular block size (that may not match at read
> time what was used to write a tape).

Looks good:
  
http://wiki.zmanda.com/index.php/FAQ:Why_can_I_write_new_labels_to_my_tapes_but_can%27t_read_the_old_ones%3F

Are there more details to add?  The 'mt' invocations in rc.conf may be
helpful to others, for example.

Dustin

-- 
Storage Software Engineer
http://www.zmanda.com


Re: Busted Tape Drive

2008-08-07 Thread Dustin J. Mitchell
On Thu, Aug 7, 2008 at 1:06 PM, Steven Backus
<[EMAIL PROTECTED]> wrote:
> Thanks to John Hein and everyone.

I haven't followed this too closely, but are there some takeaway
messages that could be worked into a FAQ here?
  http://wiki.zmanda.com/index.php/FAQ

Dustin

-- 
Storage Software Engineer
http://www.zmanda.com


Re: Busted Tape Drive

2008-08-07 Thread Steven Backus
<[EMAIL PROTECTED]> writes:
> I've seen problematic behavior when the tape unit is set to have a
> particular block size (that may not match at read time what was used
> to write a tape).

That was the problem.  In my rc.local file I have:

/bin/mt defcompression 0
/bin/mt defblksize 0

But with the mt command broken (it now uses /dev/tape as the
default instead of /dev/nst0) I should have had:

/bin/mt -f /dev/nst0 defcompression 0
/bin/mt -f /dev/nst0 defblksize 0

Thanks to John Hein and everyone.

Steve
-- 
Steven J. BackusComputer Specialist
University of Utah  E-Mail:  [EMAIL PROTECTED]
Genetic EpidemiologyAlternate:  [EMAIL PROTECTED]
391 Chipeta Way -- Suite D  Office:  801.587.9308
Salt Lake City, UT 84108-1266   http://www.math.utah.edu/~backus


Re: Busted Tape Drive

2008-08-07 Thread John E Hein
Steven Backus wrote at 10:20 -0600 on Aug  7, 2008:
 >   I've determined my drive can label tapes but can't read old
 > tapes.  I get the Input/Output error whenever trying to read a
 > previously labeled tape or dd out anything.  However, if I re-label
 > the tape it works again.  Does this indicate a failing drive?  Any
 > other ideas?

I've seen problematic behavior when the tape unit is set to have a
particular block size (that may not match at read time what was used
to write a tape).

We set the block size for the tape unit to have variable length blocks
when doing amanda writes & reads.

In FreeBSD, that's 'mt blocksize 0' and for linux, 'mt setblk 0'.
(also we set hardware compression off)

I don't know if that will help in your case or not.

I assume you've done the simple test:

dd if=/dev/random bs=32k of=/tmp/foo count=1
mt -f /dev/ rew
dd if=/tmp/foo bs=32k of=/dev/ count=1
mt -f /dev/ rew
dd of=/tmp/foo2 bs=32k if=/dev/ count=1

diff /tmp/foo /tmp/foo2


Re: Busted Tape Drive

2008-08-07 Thread Steven Backus
  I've determined my drive can label tapes but can't read old
tapes.  I get the Input/Output error whenever trying to read a
previously labeled tape or dd out anything.  However, if I re-label
the tape it works again.  Does this indicate a failing drive?  Any
other ideas?

Thanks,
  Steve
-- 
Steven J. BackusComputer Specialist
University of Utah  E-Mail:  [EMAIL PROTECTED]
Genetic EpidemiologyAlternate:  [EMAIL PROTECTED]
391 Chipeta Way -- Suite D  Office:  801.587.9308
Salt Lake City, UT 84108-1266   http://www.math.utah.edu/~backus


Re: Busted Tape Drive

2008-08-06 Thread Steven Backus
Matthew Marlowe <[EMAIL PROTECTED]> wrote:

> Are you using RHEL or Fedora? The bug is reported for fedora 8 but
> we just noticed a similar issue on a RHEL5.2 box (perhaps this is
> one of the feature updates carried over from fedora during the 5.2
> upgrade).

  I'm on RHEL 4.x, latest updates, that's when things broke.  I
have RHEL 5.x machines but if this bug is propagated throughout all
of the versions it would be a waste of time to upgrade.

> I'm looking to see what rpm or kernel is needed to downgrade.

If you don't have time, can you tell me how to do this?

  Also, I wonder what OS is being used by the other person on this
list who's having problems with /dev/nst0?

Thanks,
  Steve
-- 
Steven J. BackusComputer Specialist
University of Utah  E-Mail:  [EMAIL PROTECTED]
Genetic EpidemiologyAlternate:  [EMAIL PROTECTED]
391 Chipeta Way -- Suite D  Office:  801.587.9308
Salt Lake City, UT 84108-1266   http://www.math.utah.edu/~backus


Re: Busted Tape Drive

2008-08-05 Thread Dustin J. Mitchell
On Tue, Aug 5, 2008 at 11:09 AM, Steven Backus
<[EMAIL PROTECTED]> wrote:
> This could be it, does amanda use this for tape commands?

Amanda uses what was supplied in the TAPEDEV parameter directly.

Dustin

-- 
Storage Software Engineer
http://www.zmanda.com


Re: Busted Tape Drive

2008-08-05 Thread Steven Backus
Dustin writes:
> Amanda uses what was supplied in the TAPEDEV parameter directly.

Then someone busted more than just the mt status command:

amtape genepi current

returns:

amtape: scanning current slot in tape-changer rack:
slot 2: not an amanda tape (Input/output error)

because it was an amanda tape before the latest OS updates.

Steve
-- 
Steven J. BackusComputer Specialist
University of Utah  E-Mail:  [EMAIL PROTECTED]
Genetic EpidemiologyAlternate:  [EMAIL PROTECTED]
391 Chipeta Way -- Suite D  Office:  801.587.9308
Salt Lake City, UT 84108-1266   http://www.math.utah.edu/~backus


Re: Busted Tape Drive

2008-08-05 Thread Steven Backus
Matthew Marlowe <[EMAIL PROTECTED]> writes:

> See the following Red Hat bug:
>https://bugzilla.redhat.com/show_bug.cgi?id=289381
> 

This bug says:

"mt status" attempts to use /dev/tape, as a device, when it's a
directory

This could be it, does amanda use this for tape commands? 

> Are you using RHEL or Fedora? 

I'm using RHEL 4.x, latest updates.

> I'm looking to see what rpm or kernel is needed to downgrade.

Please let me know, I tried the previous kernel without success.

Thanks,
  Steve
-- 
Steven J. BackusComputer Specialist
University of Utah  E-Mail:  [EMAIL PROTECTED]
Genetic EpidemiologyAlternate:  [EMAIL PROTECTED]
391 Chipeta Way -- Suite D  Office:  801.587.9308
Salt Lake City, UT 84108-1266   http://www.math.utah.edu/~backus


Re: Busted Tape Drive

2008-08-05 Thread Ingo Freund

On 04.08.2008 13:45, Chris Hoogendyk wrote (please find the answer below the 
original text):



Steven Backus wrote:

  Ever since my latest update from Red Hat, my VXA-2 tape library
has stopped working.  It appears /dev/tape is now a directory
instead of a link to /dev/nst0 and every command I give to the
drive returns /dev/nst0: Input/output error.  I've tried removing
/dev/tape and linking it to /dev/nst0 with no joy.  I've also tried
using dd, which returns the same error.  I've tried re-compiling
Amanda too.  I'm running Red Hat AS 4.x and amanda 2.5.2p1, anyone
got any ideas?




newer linux Systems use udev for device files.
/dev/tape will be a directory when the system detects a tape.
Look at /etc/udev/rules.d to see what happens at boot time
or when plugging devices


-Ingo.




Re: Busted Tape Drive

2008-08-04 Thread Matthew Marlowe

Steve,


  Ever since my latest update from Red Hat, my VXA-2 tape library
has stopped working.  It appears /dev/tape is now a directory
instead of a link to /dev/nst0 and every command I give to the
drive returns /dev/nst0: Input/output error. 


See the following Red Hat bug:
  https://bugzilla.redhat.com/show_bug.cgi?id=289381

Are you using RHEL or Fedora? The bug is reported for fedora 8 but we 
just noticed a similiar issue on a RHEL5.2 box (perhaps this is one of 
the feature updates carried over from fedora during the 5.2 upgrade).
The bug indicates that the changes are being removed from fedora 
rawhide, which is good...but it's hard to understand how such a major 
change made it into RHEL.  I'm looking to see what rpm or kernel is 
needed to downgrade.


Regards,
Matt
--
DeployLinux Consulting, Inc
Senior Infrastructure Consultant
Tel: 805-857-9144  [EMAIL PROTECTED]
Yahoo IM: deploylinuxconsulting



Re: Busted Tape Drive

2008-08-04 Thread Chris Hoogendyk



Steven Backus wrote:

  Ever since my latest update from Red Hat, my VXA-2 tape library
has stopped working.  It appears /dev/tape is now a directory
instead of a link to /dev/nst0 and every command I give to the
drive returns /dev/nst0: Input/output error.  I've tried removing
/dev/tape and linking it to /dev/nst0 with no joy.  I've also tried
using dd, which returns the same error.  I've tried re-compiling
Amanda too.  I'm running Red Hat AS 4.x and amanda 2.5.2p1, anyone
got any ideas?


I'm not a linux expert, so I can't tell you how to solve the problem. 
But, perhaps I can at least point you in the right direction for 
starters. Focus on the driver for your tape library. Did you install 
this yourself originally? Or did someone else? It would seem that if the 
driver came with Red Hat Linux, an update of Red Hat wouldn't have 
broken it. In any case, dropping back to a basic tool like dd (or tar) 
for testing is a good idea until that works. It eliminates extraneous 
variables. Once your are back to the point where mt and mtx work, then 
amanda should work.



---

Chris Hoogendyk

-
  O__   Systems Administrator
 c/ /'_ --- Biology & Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~ - University of Massachusetts, Amherst 


<[EMAIL PROTECTED]>

--- 


Erdös 4