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

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]

Date:	Tue, 5 May 2009 17:57:15 +0200
From:	Philipp Reisner <philipp.reisner@...bit.com>
To:	Bart Van Assche <bart.vanassche@...il.com>
Cc:	James Bottomley <James.Bottomley@...senpartnership.com>,
	david@...g.hm, Willy Tarreau <w@....eu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Jens Axboe <jens.axboe@...cle.com>,
	Greg KH <gregkh@...e.de>, Neil Brown <neilb@...e.de>,
	Sam Ravnborg <sam@...nborg.org>, Dave Jones <davej@...hat.com>,
	Nikanth Karthikesan <knikanth@...e.de>,
	"Lars Marowsky-Bree" <lmb@...e.de>,
	Kyle Moffett <kyle@...fetthome.net>,
	Lars Ellenberg <lars.ellenberg@...bit.com>
Subject: Re: [PATCH 00/16] DRBD: a block device for HA clusters

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