3 ms·

If screw drivers are cheaper than hammers, we can just tie a bunch of screw drivers together and use them to pound in nails. Considering the seek time of the r

If screw drivers are cheaper than hammers, we can just tie a bunch of screw drivers together and use them to pound in nails. Considering the seek time of the robot arm. Striping data across four tapes just means you need to wait for the robot to grab four tapes.

mistercow 14y ago
I think brudgers was suggesting something akin to RAID 1 (mirroring, but no striping), which would, for sufficiently random access patterns, improve read performance roughly linearly as you added tape drives. The streaming speed of modern tape drives is comparable to hard drives, so striping isn't that useful anyway (and one a single tape with tapes switched out, you'd lose the physical parallelism that makes striping useful). But seek time is what really kills tape drives, and that would benefit from mirroring (like RAID 0), which is what brudgers was suggesting. Although brudgers talked about writing at different offsets, that's actually pointless if you don't rewind each tape between accesses (and why would you?). Assuming random access patterns, your read speed on the array will, on average, increase linearly with the number of tapes. This will come at the cost of write latency, the magnitude of the cost depending on how you implement the array. If the array has independent drives (which would be very expensive, but let's assume for the moment), then your write latency is always dependent on the longest seek (you have to wait for the write to occur on every tape). That means that as the number of tapes increases, your average writing latency will approach the worst case for a single tape. In other words, with an infinite number of full drives, you would always have to wait for one of the drives to seek across an entire tape. That's pretty bad news, but it's acceptable for some cases. On the other hand, if you had one drive and a tape library, your write times would really be completely unacceptable. Your linear read seek speed increase would come at the cost of a linear write seek time increase, plus a linear increase in writing throughput time.

mistercow 14y ago

I think brudgers was suggesting something akin to RAID 1 (mirroring, but no striping), which would, for sufficiently random access patterns, improve read performance roughly linearly as you added tape drives. The streaming speed of modern tape drives is comparable to hard drives, so striping isn't that useful anyway (and one a single tape with tapes switched out, you'd lose the physical parallelism that makes striping useful). But seek time is what really kills tape drives, and that would benefit from mirroring (like RAID 0), which is what brudgers was suggesting. Although brudgers talked about writing at different offsets, that's actually pointless if you don't rewind each tape between accesses (and why would you?). Assuming random access patterns, your read speed on the array will, on average, increase linearly with the number of tapes. This will come at the cost of write latency, the magnitude of the cost depending on how you implement the array. If the array has independent drives (which would be very expensive, but let's assume for the moment), then your write latency is always dependent on the longest seek (you have to wait for the write to occur on every tape). That means that as the number of tapes increases, your average writing latency will approach the worst case for a single tape. In other words, with an infinite number of full drives, you would always have to wait for one of the drives to seek across an entire tape. That's pretty bad news, but it's acceptable for some cases. On the other hand, if you had one drive and a tape library, your write times would really be completely unacceptable. Your linear read seek speed increase would come at the cost of a linear write seek time increase, plus a linear increase in writing throughput time.