John R. Jackson on Sun 26/01 17:40 -0500:
> > You describe RAID4, probably the least commonly used RAID, since it
> > means only one write request can be satisfied at once, as there is a
> > only single drive doing parity writes.  Much better is to rotate the
> > parity from one drive to the next with each write (RAID5), meaning
> > that write requests can be satisfied concurrently.
> 
> Ummm, we're talking about tapes here.  Multiple concurrent writes
> doesn't mean a whole lot :-).

Huh? I haven't read the RAIT code yet, so maybe it doesn't work like it
does for disks, but it should mean that backups finish faster, in direct
proportion to the number of drives in your RAIT set, less one (just like
disks)

I'm not talking about multiple writes to the same tape happening at
once.  With a single parity tape, all writes to any drive in the set
block on writes from any of the other drives, since they all wait on the
same drive head used to record parity information.  This limits write
speed to all the drives in the data set combined, to that of the single
parity drive.

Read operations can still go in parallel with RAIT4, but the write case
is of course what needs optimizing for a tape backup system.

> But note that doing so is going to make a "bare metal" recovery that
> much harder if amdd isn't around to help.

As long as the on-tape structure is known and consistent, it shouldn't
be that hard to do, but your point is a good one to consider when
choosing RAIT level.

> For the *specific* case of RAIT with Amanda and the "normal" block
> size, power of 2 is needed.  For anything else (including using amdd
> for other purposes), anything that is an even divisor is required.

ok, I just read the RAIT code.  A few things, which I'm sure you are
already aware of already (and now your comments make a lot of sense):

   - 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.

   - it's limited to RAIT4, and additionally:

   - it has the divisor limitation you mention due to this code:

       data_fds = pr->nfds - 1;
        if (0 != len % data_fds) {
            errno = EDOM;
            rait_debug((stderr, "rait_write:returning %d: %s\n",
                                -1,
                                strerror(errno)));
            return -1;
        }
        /* each slice gets an even portion */
        len = len / data_fds;

     (and the rest of the write implementation)

   - 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 ?

The RAIT code isn't at all generic, but that's not to say it isn't
useful or appreciated.

I guess there isn't any way, then, to employ multiple write heads at
once, without having different sets of backups that use different tape
devices.  This sounds like it would be really hard to set up with a
changer.

Anyways it looks like I will have to use the current RAIT code for now,
and live with the limitations.  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 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.  Or something like that.  I haven't really
worked on tapes...

> > It's unfortunate that he doesn't read this list :)
>
> And how would we know that?

Yes yes, read too much into the silence, plus I now see there is an
"amanda-hackers" list which is probably more appropriate for this
discussion.

> > And since no one else replied I will have to conclude that he is the
> > only one using RAIT in production.  ...
>
> Ummm, I don't follow that logic at all.  There are over 1000 addresses
> subscribed to amanda-users.  This is a "chatty" place, but not *that*
> chatty :-).  Lots of people just like to read and not post, and there
> is absolutely nothing wrong with that.  Lack of response does not
> translate to an affirmative statement.

Effectively enough, though.  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'm just saying, when considering it for a production deployment,
measuring list response to questions about it is a valid measure of its
maturity, if not an exact one.