[Lustre-devel] Commit on share
Alexander Zarochentsev
Alexander.Zarochentsev at Sun.COM
Wed Jun 11 09:46:13 PDT 2008
On 11 June 2008 19:26:19 Peter Braam wrote:
> On 6/11/08 8:21 AM, "Alexander Zarochentsev"
>
> <Alexander.Zarochentsev at Sun.COM> wrote:
> > Hello,
> >
> > On 27 May 2008 14:44:18 Peter Braam wrote:
> >> This HLD is definitely not ready at all. It is very short, lacks
> >> interaction diagrams and the arguments made are not sufficiently
> >> detailed.
> >
> > is the following definition of dependent operation more clear?
> >
> > Operation B depends on operation A if:
> >
> > 1. A and B modify the same object
> > 2. B modifies the object after A (LDLM serializes object access)
> > 3. A isn't committed yet
> > 4. A and B are issued by different clients
>
> This shows a fundamental mistake, and one I was afraid of. If a
> second client only reads uncommitted data there is already a
> dependency.
The definition above is intentionally done that way.
It is just to fit requirements from the arch page, one of them is
".. avoid non-recoverable requests". A non-recoverable request is a
request which cannot be replayed due to object version / request
version mismatch. CoS doesn't care about requests which are not
replayable and the definition reflects that.
Well, I understand now you want more than an optimization to VBR but I
had to explain the mistake.
s/modify/access/ :
1. A and B access the same object, A is a write access.
2. B accesses the object after A (LDLM serializes object access)
3. A isn't committed yet
4. A and B are issued by different clients
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?
Or we can add (results implementation complexity)
5. A depends on the result of B: file creation and readdir, creation and
deletion of the same file and so on.
> You need to read the database literature - this is standard stuff,
> here is a link to a great book:
>
> http://research.microsoft.com/~philbe/ccontrol/
> Peter
--
Alexander "Zam" Zarochentsev
Staff Engineer
Lustre Group, Sun Microsystems
More information about the lustre-devel
mailing list