>> ...  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, jrj AT purdue DOT edu