Re: [PATCH 00/16] DRBD: a block device for HA clusters

From: Philipp Reisner
Date: Tue May 05 2009 - 11:58:27 EST


On Tuesday 05 May 2009 17:03:13 Bart Van Assche wrote:
> On Tue, May 5, 2009 at 10:21 AM, Philipp Reisner
>
> <philipp.reisner@xxxxxxxxxx> wrote:
> > What we have in DRBD boils down to:
> >
> > * We obey all possible write after write dependencies in the stream of
> > writes we get from the upper layers. And generate DRBD internal
> > reorder barriers for the packet stream.
>
> Hello Philipp,
>
> I couldn't find a call to blk_queue_ordered() in the DRBD 8.3.1 source
> code. This made me wonder how DRBD obtains information about barriers
> that is generated by filesystems like ext3 with the option barrier=1 ?
>

Hi Bart,

I was refering to implicit write after write dependencies, that one
needs to obey when doing asynchronous replication.

Up to now we do not offer barrier support for the layers above us.
That will follow sooner or later.

Here is an example, why it is not completely trivial:

Imagine DRBD on top of a dm-linear on both nodes. When you start,
both dm-linear mappings sit on top of something that supports
barriers itself. -- Then the user replaces the backing device
below the dm-linear on the secondary node with something that
does not support barriers.

When we get a write request with the BIO_RW_BARRIER flag set
in from the FS, we submit this locally, ship it over to the
peer and submit it there. Unfortunately it fails now with
ENOTSUP on the peer.

We can not ship that error back to the upper layer, because
our mirror is already inconsistent. We have to resubmit
it with BIO_RW_BARRIER cleared, and other means to enforce
write ordering... Then tell the other node that we prefer
to no longer accept BIO_RW_BARRIER etc...

-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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/