Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Fri, Sep 24, 2010 at 11:12:35AM +0200, Nicolae Mihalache wrote: > Hello, > > I've been reading about the barriers (no-disk-barrier option) in drbd. > I understand that when the primary gets a IO completion notification, > it will issue a barrier request (actually start a new epoch) to the > secondary. > However, if the disk of the primary has a write cache, it will > immediately issue an IO completion notification, without actually > writing the data to the disk. So what happens is that the secondary > will use lots of barriers to guarantee the write order of the primary > while in fact the primary itself has no guarantee about the order. > > My conclusion is in contradiction with what is written in the user > guide http://www.drbd.org/users-guide/re-drbdconf.html: > > "When selecting the method you should not only base your decision on > the measurable performance. In case your backing storage device has a > volatile write cache (plain disks, RAID of plain disks) you should use > one of the first two (i.e. barrier or flush)." > > Can someone point the fault in my reasoning? Look for this message, or read the whole thread. Date: Thu, 5 Aug 2010 14:40:56 +0200 From: Lars Ellenberg <lars.ellenberg at linbit.com> Subject: Re: [DRBD-user] barrier mode on LVM containers DRBD's usage of barriers/cache flushes is to make sure we won't "forget" to resync parts that need to be synced after a node crash. -- : 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