GSOC: Device mapper mirror target

Venkatesh Srinivas me at endeavour.zapto.org
Mon Apr 25 04:28:10 PDT 2011


On Mon, Apr 25, 2011 at 6:36 AM, Adam Hoka <adam.hoka at gmail.com> wrote:
> On Mon, 25 Apr 2011 10:30:58 +0100
> Alex Hornung <ahornung at gmail.com> wrote:
>
>> On 25/04/11 10:15, Adam Hoka wrote:
>> >> I also don't see the need of delegating every write to secondary mirror
>> >> legs to a thread. You definitely need a synchronization thread, but I
>> >> think you should propagate writes to each of the mirror disks from the
>> >> same context you are in when you get the requests.
>> >
>> > That "thread" could be a workq (which will run in a different thread,
>> > obviously).
>>
>> I know what you mean, but I don't see why you would do it like that. You
>> should be dispatching writes to all the mirror disks immediately and not
>> queue them to later dispatch them for a different thread. I see no
>> advantage to that approach, it makes things more complicated and last
>> but not least it is also less robust.
>
> How do I parallelize the writes then? I dont want to queue and forget them,
> just want to something like this:
>
> - add the jobs to a list
> - run them in parallel, each in his own thread
> - wait for completion and collect return values
>
> maybe it could be implemented with something like this?
> im just not sure if I can run one task multiple times in parallel.
>
> tq = taskqueue_create("dm-mirror", M_WAITOK, taskqueue_thread_enqueue, &tq);
> taskqueue_start_threads(&sc->sc_tq, numberofmirrorlegs, TDPRI_KERN_DAEMON, -1, "dm-mirror taskq");
> ...
> taskq_enqueue(tq, dmmirror_write_task);
>
> instead of this:
>
> vn_strategy(dev1, io); // block for a while...
> vn_strategy(dev2, io);
>

vn_strategy doesn't necessarily block till an I/O completes; it merely
calls the vnode's strategy vfs op. biodone() is called from inside the
strategy path when an I/O operation is complete. The path calling
vn_strategy may wait for completion with biowait().

In the case of nata, for example, ad_strategy() kicks of an ATA
request; ad_done() is called from the ATA device interrupt and calls
biodone() to complete the request.

-- vs





More information about the Kernel mailing list