Exabyte EXB-8505XL Tape Drive
Matthew Burgess
Solaris 6. At the moment it only writes when accessing it via
/dev/rmt/0lb(n). This drops the capacity down to 2GB and of course the
transmission rate drops through the floor. If I try writing to /dev/rmt/0m
(5GB format) or /dev/rmt/0h (5GB compressed format) ufsdump complains of
write errors part way through the tape. According to the docs I've been
able to find, the EXB-8505XL is supported natively under Solaris. I took a
glance at the /kernel/drv/st.conf file anyway and was surprised to see that
all the lines are commented out apart from the "name=" ones. Is this
normal? If I change the st.conf file all I have to do is bring the system
down and do a boot -r correct? If the st.conf shouldn't need to be changed
would I be right in thinking the drive is no longer in a healthy state?
Thanks for any help.
Matt Burgess
Sean O'Neill
I have one of these beasts on my SS20. You shouldn't have to modified
anything in st.conf.
As to the tape speed, well its not a fast unit. The tapes you use in
that unit are important. It took me a while to figure out what "type"
8mm tape to use in that thing. Currently I'm using Sony-QG-112M and
Sony-QGD160M.
The QG-112M 5/10GB format tapes
The QGD160M are 7/14GB format tapes
The QGD160M are obviously a bit more expensive. Hell, Sony's in
general are more expensive.
Hope this helps.
Sean
--
........................................................
......... ..- -. .. -..- .-. ..- .-.. . ... ............
.-- .. -. -... .-.. --- .-- ... -.. .-. --- --- .-.. ...
Sean O'Neill
se...@deletethistorespond.seanoneill.deletethistorespond.info
Matthew Burgess
We're using the Sony QG-112M tapes as well, and I don't think it's these
that are causing the problem as it happens on all our tapes (but all tapes
can be written to using the /dev/rmt/0l device). Anyway, just to cure my
suspicion I edited the st.conf and did a reboot -- -r but to no avail.
Could you give me an example command-line for ufsdump that you use
successfully? At the moment I'm just using ufsdump 0uf /dev/rmt/0h /etc.
I'm now wondering whether I need to be specifying block sizes, tape
densities/sizes and the like.
Thanks again
Matthew Burgess
"Sean O'Neill"
<se...@deletethistorespond.seanoneill.deletethistorespond.info> wrote in
message news:j4uohusjhd0bgbv8v...@4ax.com...
Darren Dunham
> I'm trying to get an Exabyte EXB-8505XL tape drive to work correctly under
> Solaris 6. At the moment it only writes when accessing it via
> /dev/rmt/0lb(n). This drops the capacity down to 2GB and of course the
> transmission rate drops through the floor. If I try writing to /dev/rmt/0m
> (5GB format) or /dev/rmt/0h (5GB compressed format) ufsdump complains of
> write errors part way through the tape. According to the docs I've been
> able to find, the EXB-8505XL is supported natively under Solaris.
That's correct. If you do a 'mt -f <drive> status' and it says
something like "Exabyte EXB-8505 8mm Helical Scan", then the driver has
recognized the drive. Are you sure the media is appropriate for the
drive?
> I took a
> glance at the /kernel/drv/st.conf file anyway and was surprised to see that
> all the lines are commented out apart from the "name=" ones. Is this
> normal?
Yes. You can uncomment them (in a syntactically correct way) and modify
them if necessary.
> If I change the st.conf file all I have to do is bring the system
> down and do a boot -r correct?
'boot -r' isn't needed unless you're adding a device. The file will be
reread at driver load time. So a simple reboot is sufficient (again,
unless you're adding new hardware). Or if you're into it, you could
make sure nothing's using the tape, then modunload the 'st' driver.
When you access the tape, the driver will be reloaded, and the file
reread. /var/adm/messages should get messages from the driver at that
time with syntax errors or detected devices.
> If the st.conf shouldn't need to be changed
> would I be right in thinking the drive is no longer in a healthy
> state?
Very likely. Or you've got something else wrong not related to the
drive or driver. Suggestions: media, scsi system.
--
Darren Dunham ddu...@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
Sean O'Neill
<matthew....@bt.com> wrote:
>Cheers for that Sean,
>
>We're using the Sony QG-112M tapes as well, and I don't think it's these
>that are causing the problem as it happens on all our tapes (but all tapes
>can be written to using the /dev/rmt/0l device). Anyway, just to cure my
>suspicion I edited the st.conf and did a reboot -- -r but to no avail.
>Could you give me an example command-line for ufsdump that you use
>successfully? At the moment I'm just using ufsdump 0uf /dev/rmt/0h /etc.
>I'm now wondering whether I need to be specifying block sizes, tape
>densities/sizes and the like.
>
I don't use ufsdump for my backups. I use afbackup. But assuming I
was to do a ufsdump I would use:
ufsdump 0uf /dev/rmt/0h
just like you have above (well, for a single parition anyway). Have
you tried using tar or cpio to the tape just to rule out ufsdump (I'm
reaching I know)?
Matthew Burgess
I've tried using tar and cpio and both fail using either the 0h or 0m
devices, but both work fine with the 0l device. So, it looks as if it's
definitely something about the drive/scsi system that's causing it to spit
it's dummy. I'll look into it more on Monday (I'll be trying the drive on
another machine). Thanks again for your help,
Matt Burgess
"Sean O'Neill"
<se...@deletethistorespond.seanoneill.deletethistorespond.info> wrote in
message news:ha1phugn0ck663rqu...@4ax.com...
Darren Dunham
> I'm just using ufsdump 0uf /dev/rmt/0h /etc. I'm now wondering
> whether I need to be specifying block sizes, tape densities/sizes and
> the like.
You can try that, but it shouldn't be necessary. All those things to do
ufsdump is let it calculate the size of the tape. They don't affect the
way it writes to the tape. Since it can detect end-of-tape, they're not
very useful.
You can specify a blocking factor (like b 126) to change how many blocks
are sent to the tape at once.
Sean O'Neill
<matthew....@bt.com> wrote:
>Thanks again,
>
>I've tried using tar and cpio and both fail using either the 0h or 0m
>devices, but both work fine with the 0l device. So, it looks as if it's
>definitely something about the drive/scsi system that's causing it to spit
>it's dummy. I'll look into it more on Monday (I'll be trying the drive on
>another machine). Thanks again for your help,
>
>Matt Burgess
>
Stupid question, are you POSITIVE its a Sun Exabyte 8505XL drive ?
Dan
"Matthew Burgess" <matthew....@bt.com> wrote in message
news:afht35$eab$1...@pheidippides.axion.bt.co.uk...
> I'm trying to get an Exabyte EXB-8505XL tape drive to work correctly under
> Solaris 6. At the moment it only writes when accessing it via
> /dev/rmt/0lb(n).
Digging back in my memory... b is for berkely, and compatable with any
UNIX and therefore no compression at all really. I seem to remember using
"c" for real compression and thinking at the time that was silly why
wouldn't "h" be the highest like the man pages said? My own guess was that
"h" existed with the 8500's and when technology got better they added the
"c" (for compressed).
Good Luck!
Matthew Burgess
> Stupid question, are you POSITIVE its a Sun Exabyte 8505XL drive ?
Well, I can't be 100% positive because we don't have the official receipts
from Sun. I did an iostat -E (and an mt status) both of which tell me it's
an Exabyte model EXB-8505SMBANSH2 and it has an XL marking in the top right
corner of the front panel - so I just put 2 and 2 together (and knowing me
probably came up with 5 again!). It's enclosed in Sun's casing so I believe
it came from Sun (I suppose I could rip it out of the casing and see if
there's any other markings underneath!). I have the Sun part no. and serial
no. at work if that would clarify things. The weird thing is the "pretty
print" text in st.conf looks as if it should display 8505 for such a drive,
yet I'm getting 8500 back (this is both with and without my st.conf
modifications).
Thanks again,
Matt.
Matthew Burgess
that the drive is indeed an 8505XL, but it has pointed me to a potential
firmware problem:
Exabytes website
(http://www.exabyte.com/support/online/kb/display.cfm?id=24) states that the
firmware versions (or higher) given below are required:
EECODE: 8SE-0212 FECODE: 8SC-06S1
However the label on the drive states the following (the FECODE being
confirmed by iostat -E):
EECODE: 8SE-0161 FECODE: 8SC-06U0
Assuming the EECODE is a sequential number then it would appear that my
firmware is too old. I'm in contact with Exabyte about this now to confirm,
but I'd appreciate it if Sean, et. al could report your firmware revisions
for comparison.
Thanks,
Matt
"Dan" <bi...@microsoft.com> wrote in message
news:dccT8.50619$5M2.2...@news4.srv.hcvlny.cv.net...
Sean O'Neill
<matthew....@bt.com> wrote:
>Assuming the EECODE is a sequential number then it would appear that my
>firmware is too old. I'm in contact with Exabyte about this now to confirm,
>but I'd appreciate it if Sean, et. al could report your firmware revisions
>for comparison.
>
I'll be glad to if you tell me how to get the EECODE from my unit.
Sean O'Neill
<matthew....@bt.com> wrote:
>Assuming the EECODE is a sequential number then it would appear that my
>firmware is too old. I'm in contact with Exabyte about this now to confirm,
>but I'd appreciate it if Sean, et. al could report your firmware revisions
>for comparison.
>
If the case has to be opened, I'm not sure how to open this thing. I
don't see any screws and such to undo to open this thing.
Matthew Burgess
Is your drive enclosed in Sun's third party enclosure? If so there won't be
any screws. The trick is to find either a sturdy (i.e. industrial strength)
paperclip or a long thin screwdriver. On either side of the case are some
holes - towards the front of the case they're actually hiding the retaining
clips. Simply insert the screwdriver/paperclip into a few of these holes
(one at a time) on either side and apply fairly firm pressure - you should
hear the clip click as it comes free. I'm not sure how this affects
warrantees/guarantees so on your head be it - in no way am I advocating that
this procedure be carried out, I'm merely stating that it can be done.
There - that should cover me :)
Cheers,
Matt.
"Sean O'Neill"
<se...@deletethistorespond.seanoneill.deletethistorespond.info> wrote in
message news:mqi1iukn9imhs989l...@4ax.com...