[Lustre-devel] COS

[Lustre-devel] COS

[Peter Braam]

>> A question: the definition still counts parallel file creation as
>> dependent operation but actually the operations can be replayed
>> independently. Is the definition OK for CoS?

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

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.

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...?.)


From Alex:

it seems in recent ping-pong about version (what 1.8/2.0 is based on,
features,
etc) we forgot about busy inode issue with VBR. originally we planned to
build
VBR with fids as fid is unique ?

thanks, Alex

-------------------
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).


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).

Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20080611/8e214a89/attachment.htm>

[Lustre-devel] COS

[Alex Zhuravlev]

Peter Braam wrote:
> 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).

I think at early stage of VBR *we* decided it's not important with FIDS ...

thanks, Alex

[Lustre-devel] COS

[Mikhail Pershin]

On Thu, 12 Jun 2008 07:38:46 +0400, Peter Braam <Peter.Braam@Sun.COM>  
wrote:

>
> 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.

Though the only server is doing updates to the directory there are still  
dependencies like create() vs unlink() for the same name. E.g. lost  
create() can cause failed unlink() replay and backwards.

>
> 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).

VBR implementation handle this case, so we didn't forget about this case  
during development. This case wasn't in design and it was found during  
implementation/testing already and solution was discussed with Alex. The  
HLD itself is not yet updated for this case, I am fixing this.


-- 
Mikhail Pershin
Staff Engineer
Lustre Group
Sun Microsystems, Inc.

[Lustre-devel] COS

[Mikhail Pershin]

On Thu, 12 Jun 2008 08:24:42 +0400, Mikhail Pershin  
<Mikhail.Pershin@Sun.COM> wrote:

>
> VBR implementation handle this case, so we didn't forget about this case
> during development. This case wasn't in design and it was found during
> implementation/testing already and solution was discussed with Alex. The
> HLD itself is not yet updated for this case, I am fixing this.
>
>

Sorry, lost details here.
Actually the solution is only preventing assertion on server side and  
return version mismatch if inode can't be reused. Therefore the client  
will not be reintegrated successfully. This is supossed to be fixed fully  
with FIDs so no special workaround was made specially for 1.6

-- 
Mikhail Pershin
Staff Engineer
Lustre Group
Sun Microsystems, Inc.

[Lustre-devel] COS

[Peter Braam]

Hi Mike, Zam -

I had one more thought about COS.

Please avoid all special algorithms for Lustre 1.6, e.g.  no need for
workarounds to handle the absence of partial directory locks; we simply
should wait until Lustre 2.0 or whatever version will have that to improve
that.

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20080602/57b58ba3/attachment.htm>