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?