|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: Kai Makisara <makisara@metla.fi>
Date: Fri, 12 May 2000 11:58:35 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Cc: linux-scsi@vger.rutgers.edu
In-reply-to: <Pine.OSF.4.10.10005121229120.30352-100000@abies.metla.fi>
Message-ID: <BCBB7384BAC@rkdvmks1.ngate.uni-regensburg.de>
On 12 May 00, at 12:37, Kai Makisara wrote:
> On Fri, 12 May 2000, Ulrich Windl wrote:
>
> > Hello,
> >
> > yesterday I read a DDS1 tape on my Linux system that was created on
> > another Linux system. I noticed that the SCSI controller LED was
> > constantly on and data thoughput was incredibly slow. However I could
> > extract the tar archive with some MB.
> >
> > The syslog was full with messages like "Domain validation started",
> > "... ended sucessfully". I think these messages should not be there.
> > I don't understand the reason.
> >
> My guess is the following: the blocking factor you give tar does not match
> the physical block size on the tape. The drive is in variable block mode.
This sounds reasonable. However I'm surprised that GNU tar on one
Linux uses a different blocking factor than GNU tar on another Linux
system (actually SuSE 6.3 (write) vs. 6.4 (read)).
The write hardware was a Viper Archive (something) and the read
hardware was a HP-one. I think I can remeber that I saw a message
when extracting the tape saying something like "blocking factor 1".
> For each block the drive responds with CHECK CONDITION and the sense data
> is fetched from the drive. This data tells the tape driver what the block
> length was and it can return proper data to tar. Tar is intelligent and it
> can process the data even if the blocking factor was wrong. What is
> happening here is perfectly OK.
Unfortunately syslogd can't compact these messages (".. last message
repeated .. times").
>
> The problem is that the aic7xxx driver interprets CHECK CONDITION as a
> problem and performs domain validation (and logs this each time). This is
> what kills your performance.
>
> A short term fix for you is to find out what the physical block size on
> the tape is and use the correct blocking factor with tar. The long term
> fix is probably to modify the aic7xx driver so that it does not perform
> domain validation when there is no apparent error condition (note that for
> most devices CHECK CONDITION means something is wrong but for tapes there
> are many situations where CHECK CONDITION is the correct response from the
> drive).
Thank you very much for the reply.
Regards,
Ulrich
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |