On Mon, 27 Jan 2003, Scott Mcdermott wrote:
> 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.
That would be true, except *every* drive out there
1) buffers writes
2) writes really slowly, relative to the bus speed.
So the fact that you are writing round-robin rather than "in parallel"
(which you can really only do if you have distinct SCSI bus/fiber
paths to your various drives anyway) doesn't in practice make
much difference.
> Read operations can still go in parallel with RAIT4, but the write case
> is of course what needs optimizing for a tape backup system.
The RAIT code also does round-robin reads; once again drive buffering
makes it work quite well in practice.
> 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.
The parallelism you get is that the drives buffer before writing; and
write much more slowly than the buffers can be filled.
> - 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 reason for that was to avoid the overhead of adding a descriptor
and pad bytes to the end of the frames; this is particularly important
when you want it to work with fixed-1k-block drives and the default
amanda blocksizes...
> - 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 was initially done to be part of a different package
(the Fermi Tape Tools package) and got migrated to amanda, the
idea was to be able to move it back the other way some day.
> 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.
That's not true at all, which you'll see if you try it...
> 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.
Well, it may just mean no one who is using it happens to be reading
just this minute. I would be interested to know how many folks
are acutally using it, though.
> 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.
Ah, but what attribute of list response do you measure? Initial response
time? Quality of answers? Quantity of answers?
|