[Drbd-dev] How Locking in GFS works...

Lars Marowsky-Bree lmb at suse.de
Mon Oct 4 15:41:43 CEST 2004

On 2004-10-04T15:20:14, Lars Ellenberg <Lars.Ellenberg at linbit.com> wrote:

> "In case our user goes up the wall",
> we need to guarantee that whatever our users do,
> out lower level devices are identical. allways.

You can't. Not efficiently. You'd need global ordering and global
write/read locking. That would totally kill performance.

> so *in case* gfs had a bug, or something other does strange things with
> us, we can not trust it to not write concurrently on both nodes to the
> same block at the same time.

In case GFS or whatever else messes up it's internal write ordering and
cache coherency mechanisms, you're SOL anyway.

All what is needed is to guarantee the consistency when barriers come
down; ie, after a barrier (or tagged command sequence, as in SCSI) need
the devices be consistent (for writes which have happened so far).

> and the (wanted) side effect is, that we always know
> which regions of the device have been active,
> so we can do the resync correctly eventually.

Well, yes, but that's a different issue. Of course the activity logs etc
need to be kept.

    Lars Marowsky-Brée <lmb at suse.de>

High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company

More information about the drbd-dev mailing list