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

[Lars Ellenberg]

/ 2004-10-04 15:01:58 +0200
\ Lars Marowsky-Bree:
> On 2004-10-04T14:56:21, Philipp Reisner <philipp.reisner at linbit.com> wrote:
> 
> > This is intended as food for thought on how we should design our
> > support for shared disk file systems.
> 
> I'm still not sure what kind of special support you need. The only
> guarantee you need to provide is that after a barrier all reads on all
> nodes return the same data for those blocks affected by the flush.
> 
> The shared disk file system itself will take care of issueing
> appropriate barrier and flushing the OS caches.
> 
> Am I missing something? ;-)

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

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.

we have to assume that this can indeed happen,
and do some serialization stuff internally. just in case.

and if we know the expected access pattern of our users,
we can optimize our own internal serialization stuff to
not conflict and degrade performance,
but to only be there as a safety net.

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.

	lge