Re: kern/38643: [dM] st tape drive loses data

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

The following reply was made to PR kern/38643; it has been noted by GNATS.

From: der Mouse <mouse%Rodents-Montreal.ORG@localhost>
To: David Holland <dholland-bugs%netbsd.org@localhost>, Havard Eidnes 
<he%netbsd.org@localhost>,
        gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost,
        gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
yamt%netbsd.org@localhost,
        Manuel Bouyer <bouyer%antioche.eu.org@localhost>
Cc: 
Subject: Re: kern/38643: [dM] st tape drive loses data
Date: Tue, 2 Sep 2008 23:46:26 -0400 (EDT)

 >> So I think what's happening is that physio is firing off sixteen 64k
 >> reads, since PHYSIO_CONCURRENCY is 16 and MAXPHYS is 64k;
 > Ooh.  Yes, that explains it very neatly: where the data is going and
 > why exactly 15 records get lost.
 
 As a quick test to see if this is what's wrong, I tried hacking
 kern_physio to force concurrency to 0 (ie, effectively set
 PHYSIO_CONCURRENCY to 1).  It reduces the problem but does not cure it;
 it now appears to read two records, rather than 16, when the big read
 is attempted (I didn't have a scratch tape handy today; this is based
 on tape block numbers reported by "mt status").
 
 I don't expect to be in a position to pick this up again until
 Thursday; then, I should be able to try having st.c provide a buf to
 physio....
 
 /~\ The ASCII                          der Mouse
 \ / Ribbon Campaign
  X  Against HTML               mouse%rodents-montreal.org@localhost
 / \ Email!          7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B