Re: RE: Client fencing
Benny Halevy <bhalevy <at> panasas.com>
2007-09-02 06:44:14 GMT
Noveck, Dave wrote:
>> I still feel uncomfortable with letting the server reassign client
>> resources without fencing off clients
> As I understand it, your discomfort is due to the fact that you have no assurance that this approach can be
made to work reliably. And that means not that you have individual working implementations, but that you
believe that you can define a protocol, which when correctly implemented, will prevent the corruption
you are worried about from ever happening.
> On the other hand, we know the fencing approach would work and that is in line with all of the other pnfs
>> but I believe Dave B. that we're not making the current implementation any worse.
> I do also but I don't think that is the question. Not requiring fencing seems that it would make the protocol
being specified worse (i.e. less reliable), compared to one that does require fencing. If there is a
consensus that that gap can be closed so that we believe this change would not create a hole, then that would
> I'm not naïve. I know that despite our best efforts including formal review, we may define things that
have holes in them. We are doing our best to avoid them, mainly because dealing with holes found after the
fact is a real drag. But we should not close our eyes to a hole that exists in a standards track protocol or
knowingly create one.
> Here's where I think we should be. In this I'm going to use SHOULD and MUST but since these statements are
about what the layout-specific protocols should or must do rather than implementations directly, I'm
not sure what verbiage is appropriate, but I hope I'm being clear in any case:
> The protocol MUST ensure that when resources are transferred to another client, they are not used by the
client originally owning them and this must be ensured against any possible combination of partitions