[DRBD-user] what does drbd do with fsync?

Lars Ellenberg Lars.Ellenberg at linbit.com
Wed Dec 6 18:05:49 CET 2006

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


/ 2006-12-06 15:25:51 +0100
\ Nicolas Bouthors:
> Le 06/12/2006 08:49, Joe Buehler écrivait  :
> > I am using 0.7.21 with protocol C, if it matters.
> 
> Correct me if I'm wrong but I believe that the whole point of protocol C
> is to wait to the IO on the secondary node to be complete before
> returning success or failure to the local ap calling fsync (or any other
> file operation for that matters).
> 
> Therefore YES, it may take longer than IO on a "normal disk". If you
> want to avoid this, use protocol A, where DRBD will return success or
> failure to the app when the LOCAL IO is finished (performances will be
> very close to what you have on a single disk).

if you want to use protocol != C,
you MUST upgrade to 0.7.22.
see http://svn.drbd.org/drbd/branches/drbd-0.7/ChangeLog

/ 2006-12-06 11:00:44 -0500
\ Joe Buehler:
> Nicolas Bouthors wrote:
> 
> > Correct me if I'm wrong but I believe that the whole point of protocol C
> > is to wait to the IO on the secondary node to be complete before
> > returning success or failure to the local ap calling fsync (or any other
> > file operation for that matters).
> 
> Does fsync by an app cause *any* change on the part of drbd,

no.

> or is it just more disk writes as far as drbd is concerned?

basically yes.
the point is that the disk writes occur at all. 
without the fsync, data might just linger "some arbitrary"
time in the buffer/page cache.
if you switch the box of, now, then the data is just gone.
once you call fsync, data is flushed to disk, so drbd sees it for the
first time, and only then can do what it does.

note that even if the local/remote disks then pretend that the data was
written and drbd relays the completion events to the filesystem level,
the data might have only reached the disks built-in write cache, and
unless that is battery backed, transactions could still be lost on
sudden power failure.

-- 
: Lars Ellenberg                            Tel +43-1-8178292-0  :
: LINBIT Information Technologies GmbH      Fax +43-1-8178292-82 :
: Vivenotgasse 48, A-1120 Vienna/Europe    http://www.linbit.com :
__
please use the "List-Reply" function of your email client.



More information about the drbd-user mailing list