linux-kernel - Re: [GIT PULL] DRBD bits for 2.6.39

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 10 Mar 2011 16:20:59 +0100
From:	Jens Axboe <axboe@...nel.dk>
To:	Philipp Reisner <philipp.reisner@...bit.com>
CC:	linux-kernel@...r.kernel.org, drbd-dev@...ts.linbit.com
Subject: Re: [GIT PULL] DRBD bits for 2.6.39

On 2011-03-10 16:04, Philipp Reisner wrote:
> Am Donnerstag, 10. März 2011, um 14:16:42 schrieb Jens Axboe:
>> On 2011-03-10 13:10, Philipp Reisner wrote:
>>> [...]
>>>
>>>> Now that I have your attention... Did you look at the plugging changes?
>>>
>>> You always have it :)
>>> I looked at the changes, and I noticed that we no longer get the unplug
>>> events.
>>>
>>>> As Christoph mentioned, you seem to be passing plugging information on
>>>> the wire. What is the reason for that? With the on-stack plugging, these
>>>> events are not seen by the block device anymore.
>>>
>>> Imagine DRBD in synchronous mode (protocol C in DRBD speak) on an older
>>> kernel. We mirror a write, in order to get the write-ack packet from the
>>> peer, the peer needs to unplug as well. -> Send the unplug events via the
>>> wire.
>>>
>>> Now, it we would connect a current-head-of-git DRBD on one node to
>>> a older one (which still needs unplug packets to respond quickly),
>>> we would have a tar pit block device. (At least for single synchronous
>>> writes)
>>>
>>> We are in brainstorming mode right now here.
>>> One idea is to have a timer, that gets touched with every request we get
>>> in, in case it expires, we send out a unplug event over the wire.
>>>
>>> But having the unplug events would be more elegant of course...
>>
>> The unplug is essentially the ->request_fn() being run now. So for older
>> clients you could just always include an unplug even when you pulled
>> whatever off the queue there is and sent it to the device.
> 
> DRBD is a bio-based device. I.e. we hook into the stack by having a
> ->make_request_fn() function. 
> Are you saying that although we get the BIOs via a ->make_request_fn()
> call also our ->request_fn() will be called when it is time to send 
> an unplug hint?
> My expectation is, that as soon one uses his own ->make_request_fn()
> ->request_fn() will never get called.

Your expectation is correct. So in that case, the only UNPLUG event you
would get is if the request is marked UNPLUG, not an actual unplug
event. Just use the SYNC flag to know when to send the unplug event.


-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/