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/attachments/20080602/57b58ba3/attachment.html
>> 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/attachments/20080611/8e214a89/attachment-0001.html
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
On Thu, 12 Jun 2008 07:38:46 +0400, Peter Braam <Peter.Braam at 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.
On Thu, 12 Jun 2008 08:24:42 +0400, Mikhail Pershin <Mikhail.Pershin at 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.