From: Spencer Shepler (shepler@eng.sun.com)
Date: 05/30/02-12:42:41 PM Z
Date: Thu, 30 May 2002 12:42:41 -0500 From: Spencer Shepler <shepler@eng.sun.com> Subject: Re: uids-as-names, compound, reply cache, cabbages and kings Message-ID: <20020530174241.GI101252@sheplerathome.eng.sun.com> On Thu, Noveck, Dave wrote: ... > > So here's the ugly case. Somebody gives me a readdir > with a very small max output. It might be big enough > to hold the output for a single file in the directory > or it might not, depending on how long the string for > the uid turns out ot be. So at post-processing, I > may install the actual string if it fits, or return > a NOSPC error. > > But wait a minute. I'm doing this after processing the > request. This might have been a COMPOUND in which there > is some operation that followed the READDIR. If I fail > the readdir, then I shouldn't have done the following > operation, and if it had visible consequences then I > would have to undo that operation, which would be very > difficult or impossible to do. > > So am I screwed here? The answer is "No" because of some > interesting serendipity. Suppose someone did a COMPOUND > consisting of READDIR followed by RENAME. Or READ followed > by WRITE or by REMOVE. How could this be accommodated by > the reply cache. Not very easily. The COMPOUND is clearly > not idempotent so the reply cache information has to be saved. > But that includes the idempotent operations before the > non-idempotent including operations like READ and READDIR > that can generate lots of output. Without COMPOUND, such > operations would never have to be stored in the reply cache, > and saving large amounts of data in a reply cache is highly > undesirable. In the specific case of READDIR, the server can choose to return the fattr4_rdattr_error attribute to indicate a problem with the attributes. Therefore, if the server has enough space for the READDIR response without attributes, it doesn't have to fail the entire operation. -- Spencer
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:46 AM Z CST