Once again, the sun managers list has delivered.
The following tape drive gurus have my sincere thanks:
Rich Schultz (rich@ccrwest.org)
Harry Edmon (harry@atmos.washington.edu)
Scott Stubbs (jstubbs@utdallas.edu)
David Warm (david.warm@fi.gs.com)
Sydney S. Weinstein, CDP, CCP (syd@Myxa.COM)
Larry Kelley (ldk@lsci.com)
Jerry Ratner (jerryr@gcm.com)
My original question involved poor performance of DLT drives during
a space over filemarks operation.
It was nearly unanimous that the solution was to add ST_KNOWS_EOD as an
option in the st_conf.c entry. In doing so, the time required for a
large file space operation (mt -f /dev/dlt fsf x) was reduced from 30
minutes to 2 minutes. This is still 30 seconds longer than the spec.
called out in the DLT-2000 product manual, but it's certainly acceptable.
The winning entry for st_conf.c:
/* DEC DLT-2000 */
{
"DEC DLT2000", 3, "DEC", ST_TYPE_REEL, 16384,
( ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR | ST_KNOWS_EOD ),
400, 400,
{ 0x17, 0x18, 0x19, 0x19 },
{ 0, 0, 0, 0 },
}
I should also be noted that two persons suggested that it was a density
select problem and { 0x17, 0x18, 0x19, 0x19 } should be changed to
{0x81, 0x80, 0x18, 0x17}. According to the DLT-2000 product manual, the
density select values are:
0x16 - 10000 bpi MFM serial cart. tape X3.193-1990 (read only)
0x17 - 42500 bpi MFM serial cart. tape X3B5/91-174 - 2.6 GB
0x18 - (same as 0x17 but with 56 track pairs .vs 24) - 6.0 GB
0x19 - 62500 bpi, 64 track pairs, serial cart. tape - 10 GB
It's unclear to me exactly what magic voodoo occurs with a density select of
0x80 or 0x81, but doing so allegedly solves the problem. I did not take
time to test this. If someone would care to explain it, I will gladly
follow up with an enhanced summary.
-- - Nate Itkin - Portland Technology Development, Intel Corporation Aloha, Oregon - E-mail: Nate-Itkin@ptdcs2.intel.com
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:14 CDT