Networker

Re: [Networker] setting block size

2003-08-13 11:20:20
Subject: Re: [Networker] setting block size
From: Matt Temple <mht AT RESEARCH.DFCI.HARVARD DOT EDU>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Wed, 13 Aug 2003 11:20:16 -0400
Do I take it from this that once a tape is used in this way that
labeling
from the Legato side will fail and so the tape isn't reusable.?

                                                                               
Matt Temple

On Wednesday, Aug 13, 2003, at 10:08 US/Eastern, George Sinclair wrote:

Try creating a tar archive on a blank tape and then try re-labeling
that
tape using NetWorker. You will see the "not enough space" message.
Can't
recall if you also receive an I/O error as with a blank tape but
minimally you will see the space error.

I suppose NetWorker is trying to first read the label on the tape as
it's want to do whenever it labels a tape, but it detects a difference
in the block size maybe since tar defaults to a different size. Even
still wouldn't the difference in the format create some message. It
knows it's not a NetWorker tape, right?

George

Davina Treiber wrote:

Jose Quinteiro wrote:
Davina Treiber wrote:

I thought looking at the source was sufficient.
Nice if you have it. Generally most of us don't. And probably not
sufficient in a lot of cases.

The only such limitation I am aware of is the one I mentioned on
Windows.   Please enlighten me as to the other exceptions.
This is the only exception that I am aware of. However Windows is not
exactly a minority platform, I imagine it represents the lion's share
of
your market these days. Also Windows is frequently used in mixed
environments, e.g. Windows storage node sharing a library with Unix.


In any case, Networker is trying to set the same blocksize it would
use
in other platforms, and the driver just can't handle it.  It is, of
course, possible to mis-configure your OS (to use fixed-size blocks,
for
example) to ignore what Networker wants. But Networker wants the same
device-specific block size, regardless of platform.
On thinking it through, this is correct. The default values in Windows
are a variety of sizes, and I suppose the only reason they don't work
is
the limitations of SCSI drivers. Just modifying the scatter/gather
buffer parameters should be enough to fix the whole problem. I've
always
done the environment variable too, but I suppose that wasn't
necessary.
No harm done though.

FWIW, the "Not enough space" messages typically mean the tape is
blank,
but you read a label sucessfully.  Any errors in your system log?

... should have known that "not enough space" frequently means
that there is a block size mismatch.

That's why I said "typically".  That means "not every time."
Hmmm, I'll reserve judgement on that one. My feeling is that "Not
enough
space" only occurs when you are reading an unexpected block size and
that a totally blank tape will just give an "I/O error", but I'm not
able to check this just now so I don't have the facts to back it up.

Linux's st driver does not default to fixed-size blocks for most tape
drives I've used. AIT-3 is a notable exception.
I hope that's true. If so, it means my own misconfigured (i.e.
unconfigured) stinit.def for DLT should not cause problems with my
existing tapes when I fix it. This is something I have been a tiny bit
worried about.

The block size is set internally by Networker.  The environment
variables override the internal defaults. You absolutely DO NOT need
to
mess with these environment variables! Please don't make things more
complicated than they need be.
Many people still do. Sometimes quite noticeable performance
improvements can be gained by tuning this, particularly in SAN
environments where there is more latency.

An improperly configured st.conf can cause all sorts of blocksize
troubles.
(good details snipped)

The moral of the story is "don't mess with st.conf."  Use Sun's st
patches.  That's what Sun wants you to do, and they have good
reasons.
These days this is good advice. The st driver contains support for
most
of the devices we use. I'm still a little wary about the buffering
issue, I was told years ago by a very respected Legato Principal
Consultant that setting the buffering flag could cause data loss on
tape
spanning, and the defaults in st still use buffering. Having said that
I've never identified a case where data was lost in this situation.
But
yes, basically it is easy to "break it" using st.conf, but not
actually
possible to set the block size used by NetWorker from st.conf, as the
misconception seems to go. Of course when you get into SAN
environments
we have to go back to editing st.conf in order to configure the
required
LUNs.

I will send you my manager's contact information off-list.  Please
direct any further complaints about my postings to the list to him.
Don't bother. I'm not interested in that, I was just pointing out the
situation. Don't get me wrong, I think feedback from Legato on this
list
is very welcome, and I'd like to see more of it. When I worked for
Legato it was well known that unofficial posting to this list was
against the rules, and there were certain designated representatives
that would post to the list with Legato's backing, people such as
Shaun,
Wes, and Pip. Maybe this has changed, but I think the reason for the
rule was to ensure that all official postings were totally accurate.
In
any case there was always the "se list" for those times when any of us
were a bit unsure of our facts - I miss that resource. I know quite a
few Legato names who post under other addresses, when they feel they
have something to contribute unofficially - myself included!

I'll probably regret my previous posting. Not that I take any of the
content back, just that it's a small world, and paths cross
frequently.
I was just a little annoyed at so much inaccurate information being
posted on this subject and wanted to set the record straight in one
posting. I think it's probably time for a FAQ update.

Saludos,
Jose.
Eh up,
D.

--
Note: To sign off this list, send a "signoff networker" command via
email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

--
Note: To sign off this list, send a "signoff networker" command via
email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

========================================================
Matthew Temple                Tel:    617/632-2597
Director, Research Computing  Fax:    617/632-4012
Dana-Farber Cancer Inst       mht AT research.dfci.harvard DOT edu
44 Binney Street,  JF 314     http://research.dfci.harvard.edu
Boston, MA 02115              Choice is the Choice!

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

<Prev in Thread] Current Thread [Next in Thread>