Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Oops, that for some reason was never sent out, but hibernated the last few month in my Draft folder... As I already wrote it, why not sent it out now... On Sat, Jun 16, 2012 at 10:35:08PM -0700, Paul Theodoropoulos wrote: > On 6/16/2012 11:52 AM, Digimer wrote: > >The recent discussion on barriers and EL6's recent kernels left > >me, finally, curious about what barriers are and how they > >work/effect DRBD. > > > >Is there already a paper or article discussion this? If not, would > >someone mind explaining it here? I'd like to know, personally, > >more about barriers. Also, I think it'd be good to have it in the > >ML archives. > > > >Cheers! > > > > here's an excellent article that explains it all clearly and in detail: > > http://lwn.net/Articles/283161/ Though it is slightly outdated. Devicemapper, and therefore LVM, does support barriers meanwhile. The implementation has changed as well: Barriers are no longer Barriers (in the sense of BIO_RW_BARRIER), but you can chose to have a certain IO do FUA (forced unit access), or do a cache flush (FLUSH), or both. The BARRIER implementation was allowed to fail with "sorry, not supported", so all users needed to have some logic to catch this, and recover by disabling the use of barriers and resubmit that IO without barrier flags. The FLUSH/FUA implementation is transparent, so any necessary "strip off these flags" or retry or drain or whatever logic is somewhere in the stack where it all actually happens. It is all about how to be certain that some WRITE is in fact on stable storage (and not just some possibly volatile cache), and about write reordering. If you write some transaction, and then the commit block, you want to be certain that the commit block will hit stable storage only after all corresponding data reached stable storage, or you are no longer crash safe. And you want to be sure that, once the commit block IO is completed, it is in fact on stable storage, or you lose durability. It is unnecessary if no volatile caches are involved. For the record, since DRBD 8.4.2 and 8.3.14 (which is rc2 at the time of writing), DRBD also exposes FLUSH/FUA to upper layers (typically the file system). [This should have been done two years ago already... we somehow thought we did, but forgot to actually do it. ] Anyways, you now can mount -o barrier=1 /dev/drbd0 /mnt and it is supposed to "do the right thing". DRBD uses barriers respective flush/fua internally as well, for its metadata transactions, and, on the receiving node, whenever we close an "epoch". Which can be quite frequently, and these frequent cache flushes may cause a severe performance hit. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed