Date: Fri, 18 Sep 1998 22:40:40 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: dkelly@hiwaay.net (David Kelly) Cc: chris@shenton.org, scsi@FreeBSD.ORG Subject: Re: st0: 262144-byte record too big (reading SGI tar tape) Message-ID: <199809190440.WAA14791@panzer.plutotech.com> In-Reply-To: <199809190140.UAA04692@nospam.hiwaay.net> from David Kelly at "Sep 18, 98 08:40:51 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
[ dropping -questions from the CC list ] David Kelly wrote... > Chris Shenton writes: > > J Wunsch <j@uriah.heep.sax.de> writes: > > > > > You cannot read SGI tapes (with their default blocksize) on FreeBSD, > > > due to limitations in physio(9) (which have been constrained by older > > > SCSI controllers that cannot handle more than 16 scatter/gather > > > segments). > > > > Any suggestions for blocksize? The "st" man page suggests a maximum of > > 64KB so I was thinking 32K. Should that be OK? > > If your write the tape on the SGI with a 64k or smaller blocksize then > you'll be OK. (tar -cvb 128 file(s)...) > > You can also modify /var/sysgen/*/scsi, then build a new kernel > (autoconfig), and change your SGI's default tape blocksize. (sorry, I > forgot what directory the scsi file is in, you can't miss it. > > I'd love to see FreeBSD break the 64k barrier, at least for controllers > that can handle it. Would hope Adaptec 2940's can as SGI uses AIC7880's > in the O2 on my desk at work. This topic has come up a time or two in > discussion of CAM. In the rewrite for CAM I get the impression the > authors decided it was more important to get CAM working than to add > features such as large tape blocks. I can't blame them. Getting larger blocksizes working involves more than just tweaking the SCSI layer. If the scsi layer were the only bottleneck, it probably would have been implemented under the old SCSI layer long before the CAM work started. To get larger blocksizes we'll need some sort of buffer chaining scheme, scatter gather lists, or something like that. John Dyson talked about doing it at one point, but he's off working on other stuff. CAM can already handle large chunks of data, if you feed the data through in a way that doesn't involve physio. At Pluto, we've got a RAID application that feeds data through the passthrough driver in arbitrarily large chunks using physical memory addresses. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809190440.WAA14791>