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] [thread-next>] [day] [month] [year] [list]
Message-Id: <201103101604.48775.philipp.reisner@linbit.com>
Date:	Thu, 10 Mar 2011 16:04:48 +0100
From:	Philipp Reisner <philipp.reisner@...bit.com>
To:	Jens Axboe <axboe@...nel.dk>
Cc:	linux-kernel@...r.kernel.org, drbd-dev@...ts.linbit.com
Subject: Re: [GIT PULL] DRBD bits for 2.6.39

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.

Best,
 Phil
-- 
: Dipl-Ing Philipp Reisner
: LINBIT | Your Way to High Availability
: Tel: +43-1-8178292-50, Fax: +43-1-8178292-82
: http://www.linbit.com

DRBD(R) and LINBIT(R) are registered trademarks of LINBIT, Austria.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ