Backup Central

[amanda@backup tor]$ amtapetype -o -f /dev/nst0 -e 400G

Writing 1024 Mbyte compresseable data: 31 sec
Writing 1024 Mbyte uncompresseable data: 32 sec
Estimated time to write 2 * 409600 Mbyte: 25600 sec = 7 h 6 min
wrote 6684672 32 Kb blocks in 51 files in 5871 seconds (No space left on device)
wrote 262144 32 Kb blocks in 4 files
wrote 7012352 32 Kb blocks in 107 files in 5952 seconds (No space left on device)
define tapetype unknown-tapetype {
comment "just produced by tapetype prog (hardware compression off)"
length 214016 mbytes
filemark 0 kbytes
speed 37067 kps
}

I've done an amtapetype with this drive over a year ago and it returned this tapetype (from amanda.conf)

define tapetype otherdrive {
comment "just produced by tapetype prog (hardware compression off)"
length 402432 mbytes
filemark 0 kbytes
speed 67629 kps
}

The drive is an LTO3 HP drive.

Does this point to bad hardware? I tried two different tapes to run the tapetype - both with the same results. There are no errors in dmesg to report scsi problems during the test ..

What else could it be?

anyone?

i'm doing a tape run now, using the original tapetype definition, and it has filled a tape to around 238gb and moved onto the next one (well it has changed tapes,it's still waiting to write to tape)

is this normal?

On Fri, Mar 5, 2010 at 9:17 AM, rory_f <amanda-forum < at > backupcentral.com> wrote:
i'm doing a tape run now, using the original tapetype definition, and it has filled a tape to around 238gb and moved onto the next one (well it has changed tapes,it's still waiting to write to tape)

is this normal?

Amanda treats any error from the tape drive as EOT. It's the nature
of UNIX kernel drivers that they don't give much more information than
that. So it's quite possible that your tape drive is failing, or the
tapes are failing, and intermittent errors are causing the early EOT
indication.

Alternately, maybe the earlier amtapetype run was made with hardware
compression on? The size is about double..

Dustin

--
Open Source Storage Engineer
http://www.zmanda.com

On Fri, Mar 5, 2010 at 9:17 AM, rory_f <amanda-forum < at > backupcentral.com> wrote:
i'm doing a tape run now, using the original tapetype definition, and it has filled a tape to around 238gb and moved onto the next one (well it has changed tapes,it's still waiting to write to tape)

is this normal?

Amanda treats any error from the tape drive as EOT. It's the nature
of UNIX kernel drivers that they don't give much more information than
that. So it's quite possible that your tape drive is failing, or the
tapes are failing, and intermittent errors are causing the early EOT
indication.

Alternately, maybe the earlier amtapetype run was made with hardware
compression on? The size is about double..

Dustin

--
Open Source Storage Engineer
http://www.zmanda.com

I made sure to turn compression off and also the output of the tapetype didn't mention compression was on - it normally does if it detects compression, right?

Perhaps compression is turned on elsewhere - im not sure where though. So you think what is happening is the kernel thinks these tapes are only 200~gb and giving an EOT to amanda - when infact they are 400gb LTO3 tapes.

I doubt the tapes are failing - but i mean it is possible, i've used the same type of tapes for over 400 tapes with amanda and never seen this issue.

I'm guessing then it's the drive itself.. there's no real way to tell. This is our second tape drive, the one we have used more consistantly with Amanda is out being replaced as it died, too :/

I'll run a amtapetype again to make sure, i guess.

On Fri, Mar 5, 2010 at 9:17 AM, rory_f <amanda-forum < at >
backupcentral.com> wrote:
i'm doing a tape run now, using the original tapetype definition, and
it has filled a tape to around 238gb and moved onto the next one
(well it has changed tapes,it's still waiting to write to tape)

is this normal?

I had an LTO-3 drive start doing that last year and it turned out to be a
drive problem. It starting randomly getting EOT's after anywhere from 230
to 300 GB or so on 400GB tapes. The support contract on that library has
been a good investment, as it has had to be RMA'd twice now.

If you have an LTO-3 drive and 400/800GB tapes it should put about 400GB
post-compression data onto a tape. I use software compression and have the
drive's compression turned off, and it consistently puts a little over
416000000 bytes onto a tape when working correctly.

--
A hybrid Escalade is missing the point much in the same way that having a
diet soda with your extra large pepperoni pizza is missing the point.

Rory,

I may be wrong, nor my information obsolete for your tapedevice
but I seem to recall that if you want to actually turn off compression
you have to also relabel the tape. If it sees the amlabel was
written in compessed mode...

On Fri, Mar 05, 2010 at 12:21:32PM -0500, rory_f wrote:


Dustin J. Mitchell wrote:
On Fri, Mar 5, 2010 at 9:17 AM, rory_f <amanda-forum < at > backupcentral.com> wrote:

i'm doing a tape run now, using the original tapetype definition, and it has filled a tape to around 238gb and moved onto the next one (well it has changed tapes,it's still waiting to write to tape)

is this normal?


Amanda treats any error from the tape drive as EOT. It's the nature
of UNIX kernel drivers that they don't give much more information than
that. So it's quite possible that your tape drive is failing, or the
tapes are failing, and intermittent errors are causing the early EOT
indication.

Alternately, maybe the earlier amtapetype run was made with hardware
compression on? The size is about double..

Dustin

--
Open Source Storage Engineer
http://www.zmanda.com


I made sure to turn compression off and also the output of the tapetype didn't mention compression was on - it normally does if it detects compression, right?

Perhaps compression is turned on elsewhere - im not sure where though. So you think what is happening is the kernel thinks these tapes are only 200~gb and giving an EOT to amanda - when infact they are 400gb LTO3 tapes.

I doubt the tapes are failing - but i mean it is possible, i've used the same type of tapes for over 400 tapes with amanda and never seen this issue.

I'm guessing then it's the drive itself.. there's no real way to tell. This is our second tape drive, the one we have used more consistantly with Amanda is out being replaced as it died, too :/

I'll run a amtapetype again to make sure, i guess.

+----------------------------------------------------------------------
|This was sent by rory < at > mrxfx.com via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.
+----------------------------------------------------------------------


---
Brian R Cuttler brian.cuttler < at > wadsworth.org
Computer Systems Support (v) 518 486-1697
Wadsworth Center (f) 518 473-6384
NYS Department of Health Help Desk 518 473-0773



IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure. It
is intended only for the addressee. If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments. Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.

On Friday 05 March 2010, Brian Cuttler wrote:
Rory,

I may be wrong, nor my information obsolete for your tapedevice
but I seem to recall that if you want to actually turn off compression
you have to also relabel the tape. If it sees the amlabel was
written in compessed mode...

Yes, back when I was using tape, that was a major problem, so much so that I
finally read the first block of a new, but labeled, uncompressed tape, then
used dd to write that first block to every tape on the premises, then
forcibly relabeled them for my system. A certified PIMA... Then I bought
another case of tape from ebay, they looked new, cello wrap & the whole
maryann, but they weren't, and the whole scene had to be repeated, its a
darned virus I think.

This BTW, is not an amanda problem, its 100% the drive, it reads its own
hidden header data while 'recognizing' or 'accepting' the tape, and sets the
compression according to what it finds. So that gets reset to match the tape
any time you do a rewind, so you must do the rewind, and THEN issue the
compression off command, through mtx I think it was, and then, without
accessing the drive, write the uncompressed first block. Never give it a
chance to re-read that block until its done writing the new one..


On Fri, Mar 05, 2010 at 12:21:32PM -0500, rory_f wrote:
Dustin J. Mitchell wrote:
On Fri, Mar 5, 2010 at 9:17 AM, rory_f <amanda-forum < at >
backupcentral.com> wrote:
i'm doing a tape run now, using the original tapetype definition, and
it has filled a tape to around 238gb and moved onto the next one
(well it has changed tapes,it's still waiting to write to tape)

is this normal?

Amanda treats any error from the tape drive as EOT. It's the nature
of UNIX kernel drivers that they don't give much more information than
that. So it's quite possible that your tape drive is failing, or the
tapes are failing, and intermittent errors are causing the early EOT
indication.

Alternately, maybe the earlier amtapetype run was made with hardware
compression on? The size is about double..

Dustin

I made sure to turn compression off and also the output of the tapetype
didn't mention compression was on - it normally does if it detects
compression, right?

Perhaps compression is turned on elsewhere - im not sure where though. So
you think what is happening is the kernel thinks these tapes are only
200~gb and giving an EOT to amanda - when infact they are 400gb LTO3
tapes.

I doubt the tapes are failing - but i mean it is possible, i've used the
same type of tapes for over 400 tapes with amanda and never seen this
issue.

I'm guessing then it's the drive itself.. there's no real way to tell.
This is our second tape drive, the one we have used more consistantly
with Amanda is out being replaced as it died, too :/

I'll run a amtapetype again to make sure, i guess.

+----------------------------------------------------------------------

|This was sent by rory < at > mrxfx.com via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.

+----------------------------------------------------------------------

---
Brian R Cuttler brian.cuttler < at > wadsworth.org
Computer Systems Support (v) 518 486-1697
Wadsworth Center (f) 518 473-6384
NYS Department of Health Help Desk 518 473-0773



IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure. It
is intended only for the addressee. If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments. Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.



--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

You are as I am with You.

Gene,

I had no idea it was that difficult to reset.

I apologize if I left the impression that I thought it
was an amanda issue, I was sure it was in the HW and
the driver, but I didn't express.

In truth I seldom touch a drive for other amanda amanda
related work, only when assisting an end-user backing up
their own data or installing a new drive for an end-user use.

On Fri, Mar 05, 2010 at 01:30:43PM -0500, Gene Heskett wrote:
On Friday 05 March 2010, Brian Cuttler wrote:
Rory,

I may be wrong, nor my information obsolete for your tapedevice
but I seem to recall that if you want to actually turn off compression
you have to also relabel the tape. If it sees the amlabel was
written in compessed mode...

Yes, back when I was using tape, that was a major problem, so much so that I
finally read the first block of a new, but labeled, uncompressed tape, then
used dd to write that first block to every tape on the premises, then
forcibly relabeled them for my system. A certified PIMA... Then I bought
another case of tape from ebay, they looked new, cello wrap & the whole
maryann, but they weren't, and the whole scene had to be repeated, its a
darned virus I think.

This BTW, is not an amanda problem, its 100% the drive, it reads its own
hidden header data while 'recognizing' or 'accepting' the tape, and sets the
compression according to what it finds. So that gets reset to match the tape
any time you do a rewind, so you must do the rewind, and THEN issue the
compression off command, through mtx I think it was, and then, without
accessing the drive, write the uncompressed first block. Never give it a
chance to re-read that block until its done writing the new one..


On Fri, Mar 05, 2010 at 12:21:32PM -0500, rory_f wrote:
Dustin J. Mitchell wrote:
On Fri, Mar 5, 2010 at 9:17 AM, rory_f <amanda-forum < at >
backupcentral.com> wrote:
i'm doing a tape run now, using the original tapetype definition, and
it has filled a tape to around 238gb and moved onto the next one
(well it has changed tapes,it's still waiting to write to tape)

is this normal?

Amanda treats any error from the tape drive as EOT. It's the nature
of UNIX kernel drivers that they don't give much more information than
that. So it's quite possible that your tape drive is failing, or the
tapes are failing, and intermittent errors are causing the early EOT
indication.

Alternately, maybe the earlier amtapetype run was made with hardware
compression on? The size is about double..

Dustin

I made sure to turn compression off and also the output of the tapetype
didn't mention compression was on - it normally does if it detects
compression, right?

Perhaps compression is turned on elsewhere - im not sure where though. So
you think what is happening is the kernel thinks these tapes are only
200~gb and giving an EOT to amanda - when infact they are 400gb LTO3
tapes.

I doubt the tapes are failing - but i mean it is possible, i've used the
same type of tapes for over 400 tapes with amanda and never seen this
issue.

I'm guessing then it's the drive itself.. there's no real way to tell.
This is our second tape drive, the one we have used more consistantly
with Amanda is out being replaced as it died, too :/

I'll run a amtapetype again to make sure, i guess.

+----------------------------------------------------------------------

|This was sent by rory < at > mrxfx.com via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.

+----------------------------------------------------------------------

---
Brian R Cuttler brian.cuttler < at > wadsworth.org
Computer Systems Support (v) 518 486-1697
Wadsworth Center (f) 518 473-6384
NYS Department of Health Help Desk 518 473-0773



IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure. It
is intended only for the addressee. If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments. Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.



--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

You are as I am with You.
---
Brian R Cuttler brian.cuttler < at > wadsworth.org
Computer Systems Support (v) 518 486-1697
Wadsworth Center (f) 518 473-6384
NYS Department of Health Help Desk 518 473-0773



IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure. It
is intended only for the addressee. If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments. Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.

Gene,

I had no idea it was that difficult to reset.

I apologize if I left the impression that I thought it
was an amanda issue, I was sure it was in the HW and
the driver, but I didn't express.

In truth I seldom touch a drive for other amanda amanda
related work, only when assisting an end-user backing up
their own data or installing a new drive for an end-user use.

On Fri, Mar 05, 2010 at 01:30:43PM -0500, Gene Heskett wrote:
On Friday 05 March 2010, Brian Cuttler wrote:
Rory,

I may be wrong, nor my information obsolete for your tapedevice
but I seem to recall that if you want to actually turn off compression
you have to also relabel the tape. If it sees the amlabel was
written in compessed mode...

Yes, back when I was using tape, that was a major problem, so much so that I
finally read the first block of a new, but labeled, uncompressed tape, then
used dd to write that first block to every tape on the premises, then
forcibly relabeled them for my system. A certified PIMA... Then I bought
another case of tape from ebay, they looked new, cello wrap & the whole
maryann, but they weren't, and the whole scene had to be repeated, its a
darned virus I think.

This BTW, is not an amanda problem, its 100% the drive, it reads its own
hidden header data while 'recognizing' or 'accepting' the tape, and sets the
compression according to what it finds. So that gets reset to match the tape
any time you do a rewind, so you must do the rewind, and THEN issue the
compression off command, through mtx I think it was, and then, without
accessing the drive, write the uncompressed first block. Never give it a
chance to re-read that block until its done writing the new one..


On Fri, Mar 05, 2010 at 12:21:32PM -0500, rory_f wrote:
Dustin J. Mitchell wrote:
On Fri, Mar 5, 2010 at 9:17 AM, rory_f <amanda-forum < at >
backupcentral.com> wrote:
i'm doing a tape run now, using the original tapetype definition, and
it has filled a tape to around 238gb and moved onto the next one
(well it has changed tapes,it's still waiting to write to tape)

is this normal?

Amanda treats any error from the tape drive as EOT. It's the nature
of UNIX kernel drivers that they don't give much more information than
that. So it's quite possible that your tape drive is failing, or the
tapes are failing, and intermittent errors are causing the early EOT
indication.

Alternately, maybe the earlier amtapetype run was made with hardware
compression on? The size is about double..

Dustin

I made sure to turn compression off and also the output of the tapetype
didn't mention compression was on - it normally does if it detects
compression, right?

Perhaps compression is turned on elsewhere - im not sure where though. So
you think what is happening is the kernel thinks these tapes are only
200~gb and giving an EOT to amanda - when infact they are 400gb LTO3
tapes.

I doubt the tapes are failing - but i mean it is possible, i've used the
same type of tapes for over 400 tapes with amanda and never seen this
issue.

I'm guessing then it's the drive itself.. there's no real way to tell.
This is our second tape drive, the one we have used more consistantly
with Amanda is out being replaced as it died, too :/

I'll run a amtapetype again to make sure, i guess.

+----------------------------------------------------------------------

|This was sent by rory < at > mrxfx.com via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.

+----------------------------------------------------------------------

---
Brian R Cuttler brian.cuttler < at > wadsworth.org
Computer Systems Support (v) 518 486-1697
Wadsworth Center (f) 518 473-6384
NYS Department of Health Help Desk 518 473-0773



IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure. It
is intended only for the addressee. If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments. Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.



--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

You are as I am with You.
---
Brian R Cuttler brian.cuttler < at > wadsworth.org
Computer Systems Support (v) 518 486-1697
Wadsworth Center (f) 518 473-6384
NYS Department of Health Help Desk 518 473-0773



IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure. It
is intended only for the addressee. If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments. Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.


Hey guys. Thanks

I checked my library GUI and for the tape run i was just talking about, where it was stopping around 230gb, it seems compression WAS on. I turned it off via mt and now the gui says "off" (after stopping the run obviously)

I was *sure* i turned it off with mt before. Im doing another amtapetype now.

And the comment regarding labeling: thanks. I'll most certainly relabel all the tapes after this tapetype is done.

Thanks again guys.

On Fri, Mar 05, 2010 at 02:57:01PM -0500, rory_f wrote:

Hey guys. Thanks

I checked my library GUI and for the tape run i was just talking about, where it was stopping around 230gb, it seems compression WAS on. I turned it off via mt and now the gui says "off" (after stopping the run obviously)

I was *sure* i turned it off with mt before. Im doing another amtapetype now.

And the comment regarding labeling: thanks. I'll most certainly relabel all the tapes after this tapetype is done.

Thanks again guys.


Recalling your data in the original posting I think an amtapetype run was estimated
to take about 8 hours. I think LTO drives are capable of writing a full tape in
about 1.5 hrs, amtapetype should do two full writes, thus about 3+ hours total.

As you system seems to be writing at less than 1/2 full speed, I wonder if it
is failing to stream. If an LTO drive is not streaming, is its capacity affected
by having large gaps caused by the start and stopping action?

jl
--
Jon H. LaBadie jon < at > jgcomp.com
JG Computing
12027 Creekbend Drive (703) 787-0884
Reston, VA 20194 (703) 787-0922 (fax)

On Fri, Mar 05, 2010 at 02:57:01PM -0500, rory_f wrote:

Hey guys. Thanks

I checked my library GUI and for the tape run i was just talking about, where it was stopping around 230gb, it seems compression WAS on. I turned it off via mt and now the gui says "off" (after stopping the run obviously)

I was *sure* i turned it off with mt before. Im doing another amtapetype now.

And the comment regarding labeling: thanks. I'll most certainly relabel all the tapes after this tapetype is done.

Thanks again guys.


Recalling your data in the original posting I think an amtapetype run was estimated
to take about 8 hours. I think LTO drives are capable of writing a full tape in
about 1.5 hrs, amtapetype should do two full writes, thus about 3+ hours total.

As you system seems to be writing at less than 1/2 full speed, I wonder if it
is failing to stream. If an LTO drive is not streaming, is its capacity affected
by having large gaps caused by the start and stopping action?

jl
--
Jon H. LaBadie jon < at > jgcomp.com
JG Computing
12027 Creekbend Drive (703) 787-0884
Reston, VA 20194 (703) 787-0922 (fax)

Hey

This is true - i believe on previous amtapetype runs it estimated 4hrs. I started again , compression off. still 7hrs.

So this drive seems pooched? Anything else I can check? Could it be cables?

There are no drive errors via the kernel or on the library.

On Friday 05 March 2010, Brian Cuttler wrote:
Gene,

I had no idea it was that difficult to reset.

I apologize if I left the impression that I thought it
was an amanda issue, I was sure it was in the HW and
the driver, but I didn't express.

In truth I seldom touch a drive for other amanda amanda
related work, only when assisting an end-user backing up
their own data or installing a new drive for an end-user use.

[...]

I do think this is the list to ask about it though, as I'm not sure you would
find experienced folks to comment about such a narrow subject on some distros
mailing list.

And once the mechanism for its 'infection' is known the fix then becomes
fairly obvious.

You, I believe have far wider experience than I, you are involved with, I
assume, several hundred users, some of which probably need a reminder
occasionally, and this, in the Lazarus Long view, is just a small detail and
easily forgotten in the rush of the days work when there are that many
machines to administer.

I don't think I would want your job, being the CE at a TV station, and
resisting the urge to kill somebody who desperately needs it on a daily basis
was bad enough when there were only about 45 people to contend with. Those
that didn't want to learn, were eventually invited to find another line of
work though.

I doubt this almost virus like thing about a drives compression use will pass
anytime soon as the drive makers are bound and determined to treat us as
Neanderthal's who just moved out of our caves last week. You know, bad B.O.,
knuckles with callouses from dragging on the ground etc.

Needing a head for a DDS2 drive, I called Seacrate, who makes all those
things, all of which are fond of spending the Holidays every fall in Oklahoma
City. I wanted to see if I could obtain the drum & save me some time. They
refused to sell it to me at any price, claiming it took 20 grand worth of
special tools & gauges to do it right. That drum is about 2/3rds the size of
a std vhs machines drum, and you probably have at least 2 of them at your
home place. Piece of cake, I can install one of those and track it correctly
in 30 minutes if the machine itself has a decent transport. And I had, by
that time, replaced about half a dozen DVC-PRO
head drums, which are only about as big as a quarter & cost in the
neighborhood of 3$ to 5k $, and $17k for the tool kit. So I figured I was
capable of doing the relatively huge drum they use in those drives. Nuh, no
way Jos'e. Sigh.

I bought a then humungous 500Gb drive & switched to v-tapes. 2 drives & 4 or
5 years later its 'just' a terrabyte, and still working with much less hassle
than any of the tapes every thought of being. Generally, it Just Works(TM) &
all I do is give the email a cursory glance the next morning. It seems to me
that that is how it is supposed to work, even if I am building each new
snapshot for that nights backup when the snapshot comes out, anywhere from
once to 5 or 6 times a week. In that sense, I play the canary in the coal
mine.

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

The only two things that motivate me and that matter to me are revenge
and guilt.
-- Elvis Costello

On Fri, Mar 05, 2010 at 02:57:01PM -0500, rory_f wrote:

Hey guys. Thanks

I checked my library GUI and for the tape run i was just talking about, where it was stopping around 230gb, it seems compression WAS on. I turned it off via mt and now the gui says "off" (after stopping the run obviously)

I was *sure* i turned it off with mt before. Im doing another amtapetype now.

And the comment regarding labeling: thanks. I'll most certainly relabel all the tapes after this tapetype is done.

Thanks again guys.


Recalling your data in the original posting I think an amtapetype run was estimated
to take about 8 hours. I think LTO drives are capable of writing a full tape in
about 1.5 hrs, amtapetype should do two full writes, thus about 3+ hours total.

As you system seems to be writing at less than 1/2 full speed, I wonder if it
is failing to stream. If an LTO drive is not streaming, is its capacity affected
by having large gaps caused by the start and stopping action?

jl
--
Jon H. LaBadie jon < at > jgcomp.com
JG Computing
12027 Creekbend Drive (703) 787-0884
Reston, VA 20194 (703) 787-0922 (fax)

ok, so here is the latest one.

[amanda@backup tor]$ amtapetype -o -f /dev/nst0 -e 400G
Writing 1024 Mbyte compresseable data: 32 sec
Writing 1024 Mbyte uncompresseable data: 32 sec
Estimated time to write 2 * 409600 Mbyte: 25600 sec = 7 h 6 min
wrote 6815744 32 Kb blocks in 52 files in 5733 seconds (No space left on device)
wrote 6815744 32 Kb blocks in 104 files in 5959 seconds (No space left on device)
define tapetype unknown-tapetype {
comment "just produced by tapetype prog (hardware compression off)"
length 212992 mbytes
filemark 0 kbytes
speed 37322 kps
}

compression was set OFF in the gui for the library interfacing with the drive.

so, it seems, unless these tapes i have here are all pooched, the drive is giving me problems. ugh.

i'd try it on our other drive but ... that's out being replaced . maybe it's time to get this replaced too, while i still have the maintenance contract.

thanks for the help.. any further input on this is greatly appreciated!

On Fri, Mar 05, 2010 at 07:44:32PM -0500, rory_f wrote:


Jon LaBadie wrote:
On Fri, Mar 05, 2010 at 02:57:01PM -0500, rory_f wrote:


Hey guys. Thanks

I checked my library GUI and for the tape run i was just talking about, where it was stopping around 230gb, it seems compression WAS on. I turned it off via mt and now the gui says "off" (after stopping the run obviously)

I was *sure* i turned it off with mt before. Im doing another amtapetype now.

And the comment regarding labeling: thanks. I'll most certainly relabel all the tapes after this tapetype is done.

Thanks again guys.



Recalling your data in the original posting I think an amtapetype run was estimated
to take about 8 hours. I think LTO drives are capable of writing a full tape in
about 1.5 hrs, amtapetype should do two full writes, thus about 3+ hours total.

As you system seems to be writing at less than 1/2 full speed, I wonder if it
is failing to stream. If an LTO drive is not streaming, is its capacity affected
by having large gaps caused by the start and stopping action?



ok, so here is the latest one.

[amanda < at > backup tor]$ amtapetype -o -f /dev/nst0 -e 400G
Writing 1024 Mbyte compresseable data: 32 sec
Writing 1024 Mbyte uncompresseable data: 32 sec
Estimated time to write 2 * 409600 Mbyte: 25600 sec = 7 h 6 min
wrote 6815744 32 Kb blocks in 52 files in 5733 seconds (No space left on device)
wrote 6815744 32 Kb blocks in 104 files in 5959 seconds (No space left on device)
define tapetype unknown-tapetype {
comment "just produced by tapetype prog (hardware compression off)"
length 212992 mbytes
filemark 0 kbytes
speed 37322 kps
}

compression was set OFF in the gui for the library interfacing with the drive.

so, it seems, unless these tapes i have here are all pooched, the drive is giving me problems. ugh.

i'd try it on our other drive but ... that's out being replaced . maybe it's time to get this replaced too, while i still have the maintenance contract.

thanks for the help.. any further input on this is greatly appreciated!

When the other drive was sent out for maintenance, perhaps the cableing was
changed or disturbed.

With SCSI it is always a good idea to check hardware, card, cables, terminators, etc.
Try reseating, replacing, changing order, ...

jl
--
Jon H. LaBadie jon < at > jgcomp.com
JG Computing
12027 Creekbend Drive (703) 787-0884
Reston, VA 20194 (703) 787-0922 (fax)

On Saturday 06 March 2010, Jon LaBadie wrote:
On Fri, Mar 05, 2010 at 07:44:32PM -0500, rory_f wrote:
Jon LaBadie wrote:
On Fri, Mar 05, 2010 at 02:57:01PM -0500, rory_f wrote:
Hey guys. Thanks

I checked my library GUI and for the tape run i was just talking
about, where it was stopping around 230gb, it seems compression WAS
on. I turned it off via mt and now the gui says "off" (after stopping
the run obviously)

I was *sure* i turned it off with mt before. Im doing another
amtapetype now.

And the comment regarding labeling: thanks. I'll most certainly
relabel all the tapes after this tapetype is done.

Thanks again guys.

Recalling your data in the original posting I think an amtapetype run
was estimated to take about 8 hours. I think LTO drives are capable of
writing a full tape in about 1.5 hrs, amtapetype should do two full
writes, thus about 3+ hours total.

As you system seems to be writing at less than 1/2 full speed, I wonder
if it is failing to stream. If an LTO drive is not streaming, is its
capacity affected by having large gaps caused by the start and stopping
action?

ok, so here is the latest one.

[amanda < at > backup tor]$ amtapetype -o -f /dev/nst0 -e 400G
Writing 1024 Mbyte compresseable data: 32 sec
Writing 1024 Mbyte uncompresseable data: 32 sec
Estimated time to write 2 * 409600 Mbyte: 25600 sec = 7 h 6 min
wrote 6815744 32 Kb blocks in 52 files in 5733 seconds (No space left on
device) wrote 6815744 32 Kb blocks in 104 files in 5959 seconds (No space
left on device) define tapetype unknown-tapetype {
comment "just produced by tapetype prog (hardware compression off)"
length 212992 mbytes
filemark 0 kbytes
speed 37322 kps
}

compression was set OFF in the gui for the library interfacing with the
drive.

so, it seems, unless these tapes i have here are all pooched, the drive
is giving me problems. ugh.

i'd try it on our other drive but ... that's out being replaced .
maybe it's time to get this replaced too, while i still have the
maintenance contract.

thanks for the help.. any further input on this is greatly appreciated!

When the other drive was sent out for maintenance, perhaps the cableing was
changed or disturbed.

With SCSI it is always a good idea to check hardware, card, cables,
terminators, etc. Try reseating, replacing, changing order, ...

jl

Refresher course 101 on scsi here folks, bear with me.

Because the scsi buss is a transmission line, and demands a decent VSWR,
there are 2 things to remember when dealing with scsi.

1. A list of pre-requisites that must be met if it is to work:

1.a: termination power, it has to come from someplace, preferably the host
controller.

1.b: terminations can only be at the ends of the cable, one and exactly one
on each end. Leaving a 6" pigtail hanging out because you removed the drive
on the end of the cable, and which co-incidentally also was the terminating
device is a more common mistake than one would think.

1.c: when supplying scsi term power, there needs to be an isolation diode
between the supply and the term power line in the cable, pointed so that the
voltage can get to the cable ok, but cannot be fed back into an accessory
device after it has powered the terminators on that device.

1.d: Because this diode has a voltage drop, and the original idiots (yes,
that _is_ the right terminology) chose the resistor values based on std
values AND a 5 volt supply, so a common silicon diode virtually cannot be
used if the scsi bus is to be error free. The .65 to .7 volts of drop in an
Si diode reduces the logic one voltages noise margin by about 2/3rds. from
the target of 3.0 volts, but usually about 2.85 due to the resistors chosen,
throw in the .7 loss of the diode divided by the resistor ratio's (330 to
ground, 220 to the 5 volt line, and your logic 1 noise margin is whats left
after you subtract the 2.4 volts of a guaranteed logic 1. At 2.7 volts it
might work if the resistor tolerance are spot on. At 2.55 volts, you have
only a 150 millivolt noise margin and you may as well hold a seance, its
dead, Jim. Therefore this diode must be either a power germanium or a
schotkey rated for the current in order to get a decently low forward voltage
drop. Otherwise find a 6 volt supply for termination power. TBT, when the
psu voltage in the host machine is starting to sag in its old age, and is
already 200 millivolts low, I've been known to go get a 6 volt dc wall wart
from the shack and use that. It Just Works(TM). FWIW, I have yet to see a
Ge or Schotkey diode used on any of the major scsi vendors cards, so don't
assume that just because it says Adaptec on it, it can't be wrong. And it is
precisely those cards I've had to wall wart power several times.

If you've done all that & it still doesn't work, have a tech with a 100+ mhz
scope look at it to see why the signal echos (aka VSWR) are so bad. Maybe
you've got one bad resistor in the termination packs, so check all active
lines, 21 of them in a 50 wire scsi-II cable IIRC. Make sure he understands
exactly what the term 'VSWR' means, a great many don't, somehow thinking it
only applies to continuous wave radio/tv transmitters. VSWR is VSWR whether
its digital, or CW, its still VSWR.

2: Alternatively, you can advertise for a virgin to be sacrificed. It won't
help of course. And its a terrible waste considering how hard it is to find
one these days.

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

Reality is bad enough, why should I tell the truth?
-- Patrick Sky