ashwin chaugule <ashwin.chaugule@gmail.com> wrote: > I've also managed to hack into the kernel IDE susbsys. (ide-disk.c) to > duplicate the writes and reads for this particular disk. It's extremely unlikely you got this right. Recall that the driver has to work when out of memory, and that if you generate another write request like the request you received, then you will need another request struct and another bh struct for each one in the original. You also have to point them at the buffers in the original request, and make sue that the original request's end_bh (end_bio :) functions do not free the original buffers, but wait till your extra request has completed too. Those structs take memory, and have to come from somewhere. In other words, you have to do what the raid1 driver does. Maintain a local pool. Note that the raid1 driver chooses to be synchronous on write, that is not ack your original request until all the copies have finished. It has to do that because it can't mark sections of the target as out of date on disk, so it has to complete all writes while the knowledge that it has to is still in memory. It can't pick up later and complete them. You may wish to improve that (the FR1 driver, mine, at fr1.sf.net, can also go async on write if you want it to). > RAID 1 is useful here (although its on one disk) because , data will > not be written / read _very_ often to/from the device. And in the > event that the media is flaky, will provide like a backup. The other Provided that you know WHICH of the copies is right :-). > benefit is, I dont have to worry about the i/o errors (or any other > for that matter) while reading the contents back, the best copy > *should* be picked up by the md subsys itself. Best? Peter _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
