[DRBD-user] Is `sync` option of ext3 mount SHOULD used in drbd HA clusters?

Greg Freemyer greg.freemyer at gmail.com
Mon Sep 15 18:09:45 CEST 2008

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


On 9/15/08, Pan'ko Alexandr <A.Panko at infocom.dn.ua> wrote:
> В Пнд, 15/09/2008 в 16:11 +0200, Lars Ellenberg пишет:
>  > On Mon, Sep 15, 2008 at 04:43:49PM +0300, Pan'ko Alexandr wrote:
>  > > В Пнд, 15/09/2008 в 15:26 +0200, Lars Ellenberg пишет:
>
> > > > On Mon, Sep 15, 2008 at 03:55:55PM +0300, Pan'ko Alexandr wrote:
>  > > > > Hi.
>  > > > >
>  > > > > Let's see article from
>  > > > > http://wiki.centos.org/HowTos/Ha-Drbd
>  > > > >
>
> > > > > Let's do commands:
>  > > > >
>  > > > > [root at node1 /]# drbdadm primary repdata ; mount /dev/drbd0 /repdata
>  > > > > [root at node1 /]# dd if=/dev/urandom of=/repdata/test.file  bs=1000000c
>  > > > > count=1000; ip l set eth0 down;
>  > > >
>  > > >
>
> > > > how about
>  > > >   dd ... conv=fsync
>  > > >
>  > > > see also: man fsync
>  > >
>  > > Of cause I now about this params.
>  > > But are you sure that Tomcat and Firebird know about it too? :)
>  >
>  > that is _their_ problem.
>  > not drbd's.
>  >
>  > if it has never been submitted to drbd,
>  > drbd cannot replicate it.
>  > as simple as that.
>  > nothing drbd can do about it.
>
>  DRBD _will_ work with them.
>  In case of no sync option it will be not reliable.
>  In case of sync option it _may_ work slowly.
>  It is all I want to confirm, because I do not see doc's and mails in
>  this list archive about such problem.
>
>  I hope you do not mean that I must fsync() after _every byte_ wrote.
>
>
>  If I cancel connection in progress of dd ... conv=fsync, I get the same
>  results as with no conv=fsync.
>
>  Please try yourself and only then write here.
>
>
> > > By such commands I modeling the accident fail of one of peer in active
>  > > disk writes.
>  > >
>  > > I know how to save files ;).
>  >
>  > good.
>  > then don't complain that drbd does not replicate file you did not save.
>
>  It is live save. I act as normal program.
>  I did not say that "drbd does not replicate".
>  Drbd _does_ replicate but with no cache on ext3 filesystem.
>
>  I changed dd on simple cp command (cp /tmp/1.file /; ip l set eth0
>  down). And I do not see the file on other side at all. It is 73M length.
>  Moreover after I checked filesystem on other side - it says it is clean.
>
>  DRBD is very good project I did not saying anything bad about it.
>  I simply give facts.

Alexandr,

I believe the issue is that you need to consider the robustness of
your programs standalone prior to considering drbd's behavior.  ie.
What happens to the data your application is processing if you pull
the power cord with no warning?  Is the app robust enough to address
this?

For instance, a well written database uses ACID.
(http://en.wikipedia.org/wiki/ACID)

That ensures that when a system running a database stops unexpectedly
and then is restarted, the database will be in a well known state.

Simple utilities like dd and cp do not make any effort to ensure the
robustness of their disk activities in the presence of system
failures.  Therefore drbd has no ability to function the way you
desire.

For tools that properly use commands like fsync to ensure robustness
in the presence of system failure drbd should be a good solution.

Your idea of using the sync mount option or calling fsync after every
byte is a sledgehammer approach but even it will not work if the
applications you want to use are not designed to work in the presence
of system failures.

ie. The app has 2 things it needs to update "atomically".  They
obviously happen sequentially in the real world, so what happens if
the system fails between the first and second activity getting to
disk.  A well written application will have support code to address
this.  Simply calling fsync after every write does NOT do so.

Greg
-- 
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com


More information about the drbd-user mailing list