Date: Wed, 31 Mar 1999 20:46:45 -0600 From: David Kelly <dkelly@HiWAAY.net> To: scsi@FreeBSD.ORG Subject: cache and tape drives Message-ID: <199904010246.UAA46365@nospam.hiwaay.net>
next in thread | raw e-mail | index | archive | help
I've launched into a study of CAM and the sa driver attempting to learn where the kernel blocks on a write. Studies with kdump indicate it blocks on every write to tape. When attempting to write to 4 tape drives at once, performance suffers. And today the boss said, "We'd like to write 8 tapes at once, how many machines do we need?" Have to admit CAM is over my head as I haven't found my answer. Haven't been sniffing around with a kernel debugger either. Suspect the ccb LINK and FLAG bits control the process blocking. At the moment I no longer have access to the 4-tape machine. The last time I used it (running the Feb 8 3.0-SNAP) a tcopy between identical DDS-3 drives clocked in at a pathetic 300k/sec, previously a dd of the tape to file ran just over 1000k/sec. I learned it was faster to copy to HD, then back to tape, as writing DDS-3 tapes ran at 550k to 700k/sec. Strangely writting DDS-1 tapes always yeilded a consistant 700k/sec, and that's when I was writing 4-up. Don't remember ever writing only one DDS-1 tape at a time. In /usr/include/sys/mtio.h: #define MTCACHE 8 /* enable controller cache */ #define MTNOCACHE 9 /* disable controller cache */ but have found this ioctl's are no-ops. Know everybody has more on their plate than they can handle, that's why I've tried to find a solution myself. Have reached the limits of my abilities so its time to ask for help. "Is CAM generic enough to handle buffered writes?" Considering the example of tagged queuing on HD's its my guess that it is. "Is there a quick way to write to the tape drive until its buffer is full before blocking?" I hope so. Cdrecord apparently goes to great lengths to do this internally for CD-R's. Reproducing such an effort as cdrecord but for tapes, is beyond my motivation. Unless there are mini-errors that I never see, in my application any error reading or writing the tape drive should be considered fatal. Wondered if I could use /dev/pass1 for writing: nospam: [1006] mt -t /dev/pass1 stat mt: /dev/pass1: Operation not permitted nospam: [1007] dd if=/dev/zero bs=10k of=/dev/pass1 count=1000 dd: /dev/pass1: Invalid argument 1+0 records in 0+0 records out 0 bytes transferred in 0.000830 secs (0 bytes/sec) nospam: [1008] Apparently not. Then worried myself wondering how pass devices were mapped to other SCSI devices and didn't pursue the above any further. Pass isn't listed in dmesg, altho "device pass0" is in my kernel config. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. 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?199904010246.UAA46365>