
<HTML>

<HEAD>

<TITLE>COS</TITLE>

</HEAD>

<BODY>

<FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'>>> A question: the definition still counts parallel file creation as<BR>

>> dependent operation but actually the operations can be replayed<BR>

>> independently. Is the definition OK for CoS?<BR>

<BR>

I don’t care for the definition that was given, but parallel file creation in one directory is definitely worth discussing.<BR>

<BR>

Intuitively (in the absence of a definition) only the server is making multiple updates to the directory content and mtime, and these are not shared with the clients.  As a result, there are no dependencies for the part of the transaction that updates the directory as long as clients do not try to gain access with stat or readdir to the new entries in the directory.<BR>

<BR>

To challenge you a little further – might it be possible to get a definition of dependencies that covers cases correctly and coincides with the DLM usage?  (Notice that the book I pointed you was called “concurrency control...”.)<BR>

<BR>

<BR>

>From Alex:<BR>

<BR>

it seems in recent ping-pong about version (what 1.8/2.0 is based on, features,<BR>

etc) we forgot about busy inode issue with VBR. originally we planned to build<BR>

VBR with fids as fid is unique ?<BR>

<BR>

thanks, Alex<BR>

<BR>

-------------------<BR>

I’m extremely glad you are catching this.  Let me try to only guide the design process and not discuss how we might solve this (you are much better at that).<BR>

<BR>

<BR>

In a good design, issues like this are traceable.  If they are not, we have found a defect in the design.  Mike, Zam – how do busy inodes play into use cases and requirements shown in the design document?  To take things one step further, please define a busy inode (and I’m having this feeling that once you define this, you will immediately add a new requirement to the design document).<BR>

<BR>

Peter<BR>

</SPAN></FONT></FONT>

</BODY>

</HTML>