From: Uresh Vahalia (vahalia@emc.com)
Date: 06/11/99-12:16:53 PM Z
Message-ID: <37614485.68147A43@emc.com> Date: Fri, 11 Jun 1999 18:16:53 +0100 From: Uresh Vahalia <vahalia@emc.com> Subject: Re: COMPOUND requests, resource issues This interpretation puts the onus of error recovery on the client, which probably is the right thing. If this is the consensus, we should make it explicit in the spec. Uresh ================= "Noveck, Dave" wrote: > > > Does the protocol require the compound op to be executed > > atomically? Or > > I thought thet there was some sort of explicit statement in the > spec that atomicity was *not* required. I've just looked in the > spec in the expected places and can't find it so maybe I'm wrong > about it being explicit but I certainly get the strong impression > that there is no atomicity requirement. > > The lack of atomicity is a big issue for name caching since without > some sort of atomicity guarantee, COMPOUND cannot be used to > replace the weak-cache-consistency info stuff in v3. > > As I understand it, the model is that each op within the request is > done separately. Not only don't you have any all-or-nothing semantics, > either as far as the on-disk state or the in-core state, there are > no guarantees about what other operations (from other rpc requests) > get done between two ops of a request. > > So, if you do (on some file handle), READDIR followed GETATTR and the > READDIR returns 50 file entries, GETATTR may return attributes after > 50 more files were added to the directory, or the GETATTR may return > ESTALE since all of the fifty entries were removed and a RMDIR done > between the READDIR and the GETATTR. > > Unless you're careful, you're going to be flushing bugs out of client > handling for this stuff long after the nfs-v5 working group has started > to work. > > > does it ask the client to ensure any atomicity it needs by making lock > > requests as part of the compound op? > > If a client would need locking if he were doing the individual ops > as separate rpc's, he will need exactly the same locking if he is > issuing those same ops as a COMPOUND request. > > > 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. > > I don't think so. The server fails some op and doesn't do subsequent > ops, but since there is no all-or-nothing semantics, preceding ops > have been done successfully. This includes LOCK requests. They have > been done, and don't need to be undone. > > > 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)". > > I don't think this is a problem as long as the response gives you > enough information to recover (which includes where you were and > what the current file handle is). You can then recover from a > transient failure (JUKEBOX??) by issuing PUTFH followed the ops > starting at the one that failed. For other errors, you have to > decide what you would have done in the event of a failure of a > given op if it were issued as an independent rpc and then do > those operations instead. > the opsd
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:13 AM Z CST