>> ... To do parallelism at user level would require something like >> ..., or asynchronous I/O calls ... > >What about just using the POSIX.1b AIO interface? ...
Ummm, isn't that what I just said? :-) >Is looks reasonably >portable. Failing that, using a shared mmap segment between one fork >per tape might work. It could just be surrounded by the appropriate >ifdefs for the OS facility. Agreed. And if the shared memory stuff was used, the same #ifdef's that control taper would be appropriate. >Which interface is preferred? I think just construction a single >lio_listio() with an IO for each tape device participating in the >stripe, then utilizing a MODE of LIO_WAIT to block until done ... I think you're probably right, although I'd be interested in seeing some test results to make sure it really bought any speedup. I've found the theory of what should happen and reality of what does are often not the same thing :-). This would also require **serious** testing to make sure the vendor didn't just slap together the routines without really testing them (not that that has ever happened :-). >I was thinking of putting this case if the special characters `[' and >`]' are found in the RAIT string, so we could have devices like this: > > tapedev = "rait:/dev/rmt/{0,1,2,3[5]}n" I think I'd rather we just create a new virtualtape structure entry so it would be "rait5:/dev/rmt/{0,1,2,3}n". That would be a lot more intuitive. It's been a while since I dug through the code, but I'm pretty sure the drivers can see their own name (through the tape_info structure), so the existing output-rait code could be borrowed as much as possible and only the I/O section tweaked to do the async I/O and/or RAIT5. To slightly ease the recovery situation, should the parity device be reset to the "rightmost" device at the start of each file? If not, you'd have to scan the whole tape to know which was the parity block. You couldn't fsf to the file you want and start reading because the parity block could be from any one of the drives, depending on how many blocks had been written up to that point. Not to mention not knowing which block to make the parity block if you fsf and then start writing more data. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]