>   - it doesn't have any parallelism at all, so it gains no concurrency
>     advantages; it simply loops among the data set members, does one
>     write, blocks, does the other, etc then write the parity tape.

Correct.  To do parallelism at user level would require something like a
shared memory buffer and forked processes (ala the two halves of taper),
or asynchronous I/O calls or threads, all of which use various levels
of OS specific capabilities (and stability).

>   - the #ifdef NO_AMANDA stuff is pretty much exact duplication.
>     Anyone consider just moving this out into a library instead of
>     duplicating whole routines in rait-*.c ?

Yes, but Marc Mengel really (really :-) wanted to keep the code isolated
from Amanda so it could be used in other packages, so we ended up with
the "NO_AMANDA" stuff.

>...  I will perhaps try to implement a
>generic parallel RAIT5 and RAIT0 if I have some time, but I don't know.
>Is anyone else working on it?  ...

I doubt it.

>I see that there is a new event API that
>was put into the 2.5 tree.  That might possibly be used to set up
>non-blocking tape IO with a rotating parity stripe, which could be a
>good start at doing RAIT5.  ...

The event code may or may not help.  The real problem is the use of
the write() system call which, by definition, blocks.  But use of other
methods brings up all sorts of cross platform compatibility issues.

>...  If no one speaks up about RAIT, it means no
>one is using it.  And if they are using it in isolation, they may as
>well not be using it.

I guess we'll have to agree to disagree about this :-).

John R. Jackson, Technical Software Specialist, jrj AT purdue DOT edu