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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
