Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 01/17/2012 01:09 PM, Luis M. Carril wrote: > > El 17/01/2012 18:56, Digimer escribió: >> On 01/17/2012 12:32 PM, Luis M. Carril wrote: >>> Hello, >>> >>> Ok, the fencing and splitbrain mechanisms only enter to play when >>> both nodes meet again after some failure. >>> So... meanwhile the nodes doesn´t connect their peer they disallow >>> IO to the volume? >>> >>> Regards >> No, if both nodes go Standalone and Primary, both will allow access to >> the underlying storage, which results in a split brain. Fencing kills >> one of the nodes (either the defective one or the slower one) preventing >> it from changing it's underlying storage. > Umph, but actually I'm testing to drop one node meanwhile it is writing > in the volume, and the volume in the surviving node is stalled > (drbd-overview freezes, but /proc/drbd shows > that it is WTFConnection, Primary and Uptodate), even if I make drbdadm > disconnect manually to make it go StandAlone, IO operations freeze on > the directory. > > Maybe is an issue related to OCFS... Possibly, I use GFS2, not OCFS, so I can't speak to it's behaviour. I can say though that GFS2 will also block when a node it the cluster disappears, and it will remain blocked until it gets confirmation that the lost node was fenced. This is by design, as a hung cluster is better than a corrupted one. :) -- Digimer E-Mail: digimer at alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org "omg my singularity battery is dead again. stupid hawking radiation." - epitron