From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 4 Oct 2004 15:41:43 +0200 From: Lars Marowsky-Bree To: drbd-dev@lists.linbit.com Subject: Re: [Drbd-dev] How Locking in GFS works... Message-ID: <20041004134143.GX1542@marowsky-bree.de> References: <200410041456.21841.philipp.reisner@linbit.com> <20041004130158.GP1542@marowsky-bree.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: Coordination of development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 2004-10-04T15:20:14, Lars Ellenberg 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. Sincerely, Lars Marowsky-Brée -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX AG - A Novell company