From: Gordon Waidhofer (gww@traakan.com)
Date: 06/11/99-12:14:22 AM Z
Message-ID: <37609B2E.41C67EA6@traakan.com> Date: Thu, 10 Jun 1999 22:14:22 -0700 From: Gordon Waidhofer <gww@traakan.com> Subject: Re: COMPOUND requests, resource issues I think it would be interesting and cool to have COMPOUND ops be atomic (all or none). But, I think it's too much to ask for NFSv4. Margo Seltzer, et al, did a lot of work on Transaction Processing on UNIX -- large sequences of API calls which are atomic. Other than Seltzer's API modifications, I'm unaware of an API that would take advantage of atomic COMPOUND operations. Issues like this should be resolved in terms of what's appropriate for the client-side APIs. Atomicity isn't strictly necessary. Without a bona-fide requirement, we'll get it wrong. Uresh's point is valid, and merits answer. However, I don't believe there is an API that could generate such a sequence. Client-sides which have reason to use such COMPOUNDs should be prepared to do error recovery, rather than something automatic. For example, perhaps holding the lock is exactly the right thing in order to allow the client-side to back-out the incomplete COMPOUND, then free the lock. Regards, -gww Uresh Vahalia wrote: > > Does the protocol require the compound op to be executed atomically? Or > does it ask the client to ensure any atomicity it needs by making lock > requests as part of the compound op? In the latter case, we have a > strange condition if the request fails after one or more > client-requested locks have been acquired. The server would need to > keep track of these and release them before failing the request. This > leads to a different issue. If the compound op must be executed as "all > or nothing", some of the problems Dave has mentioned become manifest. > Even if the server may execute only part of the compound op, it may not > be possible to recover from a sequence such as "lock, op1, op2, ... opn > (fails)". > > Uresh > > =================== > > "Noveck, Dave" wrote: > > > Thinking about coding up support for COMPOUND requests (it > > "concentrates the mind wonderfully"), there seem to be a fair > > number of potential resource allocation problems particularly > > involving saving results from non-idempotent requests. > > > > In the first place, there don't seem to be any limits on > > the number of ops that one might have to deal with in a > > compound request, other than those imposed by the transport, > > so we are talking about as many ops as fit in 32K (or is it > > 64K?) so we could be talking about hundreds or even a thousand > > ops in a request and this makes me nervous both from a resource > > allocation and client fairness point of view. I would be a > > lot more comfortable if there were limits on the number of > > ops. Does anyone think a 64 op limit is too restrictive? > > > > Even with a better op count limit, there are still resource > > allocation issues. The basic problem is that any scheme in > > which you allocate resources incrementally has an exposure > > to deadlock so if you want to avoid that possiblity you have > > to allocate all of the resources that you are going to need > > in advance. This leaves you with a choice of always allocating > > the maximum or pre-scanning the request to figure out what > > will be needed. As I understand COMPOUND, the latter doesn't > > seem very easy. The length of each op has all kinds of which > > makes it difficult to scan from op to op. A length field for > > each op would make it easy to make a preparatory scan of the > > whole request. > > > > Another approach to avoiding the deadlock problem is to allow > > the server to bail if resource constraints make it impossible > > to finish all the ops. This would put the onus on the client > > to retry the uncompleted ops. Right now, the spec says that > > the client is responsible for recovering from error, but I > > interpret that as obliging him to retry to recover from a class > > of transient errors. I'm guessing that some microscopically > > thin servers may have to bail sometimes and it should be clear > > what the client's obligations are. > > > > Although it may be possible, I'm not clear exactly how a client > > would recover a hypothetical NFS4ERR_RESOURCE. The problem is > > determining the current file handle to start the retried > > segment of the request. Shouldn't the current file handle > > always be part of the response to COMPOUND? This would make > > things a lot easier. -- ================================================================== Gordon W Waidhofer Traakan Software, Inc. gww@traakan.com 111 Main St., Suite #5 650-947-1583 Direct Los Altos, CA 94042 650-947-1580 Main http://www.traakan.com 650-947-1588 Fax
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:12 AM Z CST