On Thu, Apr 26, 2012 at 12:59 AM, Emmanuel Noobadmin <centos.admin@xxxxxxxxx> wrote: > On 4/25/12, Alex <creamyfish@xxxxxxxxx> wrote: >> I can see that you are trying very hard to fit a new picture into an old >> frame. But with new technology there is always new possibilities. For >> example, what I am thinking is: with the new laser write head, it doesn't >> necessarily require the head to stay very close to the platter since laser >> doesn't fade away with longer distance, which may enable a design that > > The strength of the laser will fall as the distance to the media > increases, wouldn't it? Thanks for David answering this for me. > >> the head turns(the platter doesn't have to be round) instead of spinning >> the platter; hence the "Data rate is a product of [density * RPM]" >> statement falls apart. What is more, if the cost is justified, one may >> even design a disk with multiple write heads to increase the bandwidth >> since now we are free from the fluid mechanic interaction between the >> head and the platter. Both of these may lead to independent increase >> of data rate. I am having these thoughts because it's been an endless > > But Ostler's technique only increases the write speed and admits in a > Wired.com article there is still no faster/other way to read the data. > So we would still be stuck with the rotating disk and the magnetic > reading heads until some other breakthrough happens. Ostler admits that in his response to my e-mails too. > > Going back into the context of parity RAID rebuild, we would still be > bottlenecked on the write side wouldn't we since bits on the > replacement drive can only be calculated after reading the rest of the > drives. Yes if we can't make reading as fast as writing. But in general having a disk with write speed faster than read speed might still be an interesting choice for applications with a lot of disk write. Cheers, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
