![]() | |||||||||||||
Messages in this thread |
On Thursday 28 April 2005 12:45, Lars Marowsky-Bree wrote: > On 2005-04-28T09:39:22, Daniel McNeil <daniel@osdl.org> wrote: > > Since a DLM is a distributed lock manager, its usage is entirely for > > locking some shared resource (might not be storage, might be shared > > state, shared data, etc). If the DLM can grant a lock, but not > > guarantee that other nodes (including the ones that have been kicked > > out of the cluster membership) do not have a conflicting DLM lock, then > > any applications that depend on the DLM for protection/coordination > > be in trouble. Doesn't the GFS code depend on the DLM not being > > recovered until after fencing of dead nodes? > > It makes a whole lot of sense to combine a DLM with (appropriate) > fencing so that the shared resources are protected. I understood David's > comment to rather imply that fencing is assumed to happen outside the > DLM's world in a different component; ie more of a comment on sane > modularization instead of sane real-world configuration. But just because fencing is supposed to happen in an external component, we can't wave our hands at it and skip the analysis. We _must_ identify the fencing assumptions and trace the fencing paths with respect to every recovery algorithm in every cluster component, including the dlm. I suspect that when we do get around to properly scrutinizing fencing requirements of specific recovery algorithms, we will find that the fencing system currently on offer for gfs needs a little work. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-04-29 08:30 [W:0.486 / U:1.100 seconds] ©2003-2008 Jasper Spaans | |||||||||||||