Networker

Re: [Networker] setting block size

2003-08-13 05:15:02
Subject: Re: [Networker] setting block size
From: Davina Treiber <Treiber AT HOTPOP DOT COM>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Wed, 13 Aug 2003 11:08:08 +0100
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

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