Kai Makisara wrote:
> The driver reads the block limits when the device is opened and it checks
> that the block size for fixed block mode does not exceed these limits. In
> variable block mode the check is left for the drive. The user sees the
> error anyway.
>
> If the driver would check the byte count against the limits, the driver
> could return EINVAL instead of EIO. But would this added code actually
> help anyone?
Hmm, off-hand, does MTIOCGET have a field that tells the max block size?
The driver definitely knows the max block size, but does the
application?
At the moment it's trial-and-error as to whether any given BRUBUFSIZE
(size we use in write(2) ) works with a given drive. As Matt Jacob
noted, new high speed drives want a big block size for best performance.
But right now we're having to keep our recommendation down to 32K block
size max, because that's the max that we can guarantee work under all
circumstances.
I guess the next little utility I'll write using the generic mtxl SCSI
library is a utility that scans the SCSI bus looking for tape drives and
reporting all sorts of neat stuff about them like, e.g., the max block
size they'll support... I'm not sure enhancing mtio would be the right
solution here, since mtio has to work with IDE and FTAPE tape drives too
(as much as we all wish 'ftape' would go away :-). Besides, the mtxl
library works cross-platform, meaning that the utility would be useful
for FreeBSD folks too (as well as folks on other maybe-supported
platforms like SGI or Solaris, but I've never tested it there).
--
Eric Lee Green [EMAIL PROTECTED]
http://members.tripod.com/e_l_green/
There Is No Conspiracy
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
