October 2014 - Asg - mailman3.cels.anl.gov

[aesop] #38: bracketed single-line if statements
by aesop 11 May '15

11 May '15

#38: bracketed single-line if statements --------------------------------+------------------------------------------- Reporter: gcdanie@… | Type: defect Status: new | Priority: don't know Component: don't know | Version: Keywords: | --------------------------------+------------------------------------------- When compiling a non-blocking function (e.g., without a __blocking identifier), should that function contain a single line if statement enclosed in brackets (as below), the aesop compiler will error (as below). if (condition) { return something; } aatree.c:79:1: error: stray ‘#’ in program aatree.c:79:7: warning: statement with no effect [-Wunused-value] aatree.c:79:10: error: expected ‘;’ before string constant aatree.c:81:31: error: ‘dir’ undeclared (first use in this function) aatree.c:81:31: note: each undeclared identifier is reported only once for each function it appears in aatree.c: In function ‘__ae_worker_treenode_traverse’: -- Ticket URL: <http://trac.mcs.anl.gov/projects/aesop/ticket/38> aesop <https://trac.mcs.anl.gov/projects/aesop> The Aesop Language

2 3

[aesop] #46: parallelfor2 test failure
by aesop 20 Mar '15

20 Mar '15

#46: parallelfor2 test failure -------------------------+-------------------------------------------------- Reporter: carns | Owner: Type: defect | Status: new Priority: minor | Component: don't know Version: devel branch | Keywords: -------------------------+-------------------------------------------------- The parser/tests/blocking/parallelfor2 test program fails with the following assertion: {{{ parallelfor2: /home/pcarns/working/aesop-devel/build/include/aesop/ae- ctl.h:229: ae_ctl_done: Assertion `refcount >= 0' failed. Aborted (core dumped) }}} -- Ticket URL: <https://trac.mcs.anl.gov/projects/aesop/ticket/46> aesop <https://trac.mcs.anl.gov/projects/aesop> The Aesop Language

1 3

Re: [ASG] [EXTERNAL] Re: ASG support for distributed transactions
by Phil Carns 04 Nov '14

04 Nov '14

Hi Lee, Thanks for the clarifications. My initial reaction is that it makes sense to agree on how to do async operations, and probably a batch construct as well. I don't think that Triton will support arbitrary transactions, but that doesn't mean we can't conform to those two pieces listed above. If nothing else or our end we could use them to support things like the MPI-IO non-blocking API. There are also a couple of things about Triton's data model that diverge from some of the assumptions in your proposal. This isn't a good or a bad thing, its just different. I'll point out a couple of things that might be of interest, though: - Assuming that a target is analogous to a server (or a "location" in ASG API terminology), Triton won't understand targets at the ASG API level. It operates in terms of objects, and those objects are mapped to servers automatically. That means we can't really tell if a batch will be constrained to a particular target unless the batch only touches a single object. Even then it might transparently move if servers fail while the operations are in flight. I think the thing to do from Triton's point of view will be to let asynchronous/batch operations access whatever they are going to access, regardless of what servers it hits. - Any transaction in Triton (even to a single object) would be a distributed transaction. We do live replication by default, so you would have to coordinate across replicas. This is relatively straightforward for simple conditionals, but generalized transactions are quite a bit different. I don't know that those two restrictions will be for eternity, but I think it is a safe bet we'll need to stick to them to get to an early prototype. FYI, Rob is on vacation this week; he may have some additional commentary when he gets back as well. thanks, -Phil On 10/23/2014 01:12 PM, Ward, Lee wrote: > Hi Phil, > > Top-reply because I'm going to answer your questions in reverse orderï¿½ > > I'm advocating distributed transaction *support* but not actually supplying the manager. I want to offer protocol that allows the caller to craft their own manager. That said, yes, I'm offering protocol that directly supports two-phase commit because I believe at least some other protocols can map their semantics to what I propose without undue strain. If we want to support real three-phase commit then we will need an ask-commit operation and the targets will need timeout values. three-phase commit can handle communication errors but, as always, not much can be done about storage-related errors in the final phase. > > Since two-phase commit requires transaction support on all affected databases, I proposed protocol for that too. Whether a particular storage target in sirocco/triton is handling a transaction or a sub-transaction is relative and also need not be known to the particular target in this proposal. A single target does not need two-phase commit since a failed commit operation can be rolled back (or not rolled forward if you do it that way). You can use the pre-commit operation if you wish but it buys you nothing in this case. Same thing happens whether you use it or not. > > If the global transaction is distributed, the target still need not know it is part of a larger transaction but the transaction manager really must use a protocol to make sure the sub-transactions are durable everywhere. > > All I'm proposing is the protocol necessary to accomplish local transactions, with an extra call that allows an external entity to drive the final commit as a two-phase operation. The caller still needs to manage and drive the global (super?) transaction itself. > > Two-phase commit works like thisï¿½ > > The caller generates a global transaction, one that spans multiple databases (multiple storage targets in our case). When the caller commits, the transaction manager enters a two-phase algorithm. > > Phase 1) Ask all the databases to prepare for a commit of their sub-transactions. If any refuse or fail then all databases are asked to abort their sub-trasactions and an error is returned to the caller. We cannot proceed into phase 2 until all involved databases report they are ready. > Phase 2) Ask all the databases to finally commit. Once any database has received the commit request then the manager must make sure *all* do finally commit. There is no way to unwind this phase. It either happens or corruption occurs. > > So, pre-commit is the operation used in phase 1, above, to ask the "are you ready" question. It's more than an ask, though. Since phase 2 must not fail the pre-commit tries to do everything it can to mitigate risk in phase 2. Usually, that's things like flushing the journal and adding a dummy record to hold the expected commit in phase 2 in order to test the waters for the final durable write of that expected commit record. The actual work that needs to be done in phase 2 should be very, very little. > > I am trying to discuss what we should offer in our ASG API and it doesn't need to know anything about distributed transactions since I want the caller to write their own manager. Thus, a batch can only be shipped to a single target, a batch with the transactional flag can only be shipped to a single target. Batch-group/Transaction-group identifiers are unique only relative to a particular storage target, etcï¿½ > > A couple of examples of how I anticipate these proposed additions in use: > > I: SImple transaction > rqstgrp = ASG_BEGIN_BATCH(<no-parent>, target, do-this-in-order) > xgrp = ASG_BEGIN_BATCH (rqstgrp, <no-target>, be-a-transaction) > ASG_AWRITE(xgrp, some-rec, ï¿½) > ASG_AWRITE(xgrp, some-other-rec, ï¿½) > ASG_END_BATCH(xgrp) > ASG_ACOMMIT(xgrp) > ASG_END_BATCH(rqstgrp) > > II: Distributed transaction > rqst1grp = ASG_BEGIN_BATCH(<no-parent>, target1, do-this-in-order) > x1grp = ASG_BEGIN_BATCH (rqst1grp, <no-target>, be-a-transaction) > ASG_AWRITE(x1grp, some-rec, ï¿½) > ASG_AWRITE(x1grp, some-other-rec, ï¿½) > ASG_END_BATCH(x1grp) > ASG_APRECOMMIT(x1grp) > ASG_END_BATCH(rqst1grp) > rqst2grp = ASG_BEGIN_BATCH(<no-parent>, target2, do-this-in-order) > x2grp = ASG_BEGIN_BATCH (rqst2grp, <no-target>, be-a-transaction) > ASG_AWRITE(x2grp, some-rec, ï¿½) > ASG_AWRITE(x2grp, some-other-rec, ï¿½) > ASG_END_BATCH(x2grp) > ASG_APRECOMMIT(x2grp) > ASG_END_BATCH(rqst2grp) > ï¿½ wait for the two request group batches to complete and... > if success from all: > ASG_ACOMMIT(rqst1grp) > ASG_ACOMMIT(rqst2grp) > if (!success) PANIC-because-we-are-now-in-a-world-of-hurt > otherwise: > ASG_AABORT(rqst1grp) > ASG_AABORT(rqst2grp) > > I hope this helpsï¿½ > > --Lee > > On Oct 23, 2014, at 9:31 AM, Phil Carns wrote: > >> On 10/22/2014 04:26 PM, Ward, Lee wrote: >>> A long, boring, letter/whitepaper discussing what we might do to support distributed transactions is attached. Please weigh in. Thanks. >>> >>> --Lee >> Hi Lee, >> >> Before commenting on the concept as a whole, can I ask for a couple of technical clarifications? >> >> a) What is a pre-commit? >> >> b) Can a batch (and thus a transaction) span servers/targets? The "discussion" section advocates for transactions that span targets, but then later text indicates that batches will be issued against a single server. My guess would be that this means that transactions can indeed span servers, but that the batch will be sent to a single server that will act as a coordinator/delegator. Is that the correct assumption? >> >> thanks, >> -Phil >> _______________________________________________ >> ASG mailing list >> ASG(a)lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/asg

2 1

Weekly Report
by Gim Jongmin 27 Oct '14

27 Oct '14

Dear All, We are writing and debugging the final source code which applies the recovery policies we have been discussed. This work will be continued as well as the preparation of presentation. Sincerely, Jongmin -- Jongmin Gim Post-Doctoral Research Associate Dept. of Elecrical and Computer Enginerring Texas A&M University 333B Wisenbaker College Station, TX 77843-3259 Phone: 979-587-8311

1 0

Weekly report
by Guoxin Liu 27 Oct '14

27 Oct '14

Dear All, In the last week, we have finished the design of the data servers load balancing problem with replication cost minimization. We converted the problem to a minimum-weight perfect matching problem to solve it. In this week, we will continue working on the work load consolidation to save energy. Best Regards! Guoxin Liu PHD Candidate ECE, Clemson University

1 0

weekly report
by jingxuan 27 Oct '14

27 Oct '14

Hi, everyone, For our next deliverable work, design and implementation for data exfiltration and privilege escalation, we compared traditional definition with our research domain, and gave our definition based on the terminology and assumption of our project. Also, we were reorganizing our simulation code from ROSS to CODES, it seems that CODES has a lot of API and functions that we can utilize directly and conveniently. Jingxuan SUN Holcombe Department of Electrical and Computer Engineering Clemson University Tel:864-643-8210 Email: jingxus(a)g.clemson.edu

1 0

ANL Weekly Status - 20141027
by Harms, Kevin N. 27 Oct '14

27 Oct '14

No interesting updates for this week. We continue to work on our prototype. kevin

1 0

20141027 - Sandia Status
by Danielson, Geoffrey Charles 27 Oct '14

27 Oct '14

All, Last week, Sandia worked on: GPU RAID with the Clemson team, An event driven sirocco infrastructure incorporating SSM and our wire protocol Regards, Geoff Danielson gcdanie(a)sandia.gov Geoffrey.Danielson(a)hp.com Cell: 505-263-0751

1 0

Re: [ASG] ASG support for distributed transactions
by Phil Carns 23 Oct '14

23 Oct '14

On 10/22/2014 04:26 PM, Ward, Lee wrote: > A long, boring, letter/whitepaper discussing what we might do to support distributed transactions is attached. Please weigh in. Thanks. > > --Lee Hi Lee, Before commenting on the concept as a whole, can I ask for a couple of technical clarifications? a) What is a pre-commit? b) Can a batch (and thus a transaction) span servers/targets? The "discussion" section advocates for transactions that span targets, but then later text indicates that batches will be issued against a single server. My guess would be that this means that transactions can indeed span servers, but that the batch will be sent to a single server that will act as a coordinator/delegator. Is that the correct assumption? thanks, -Phil

2 2

ASG support for distributed transactions
by Ward, Lee 22 Oct '14

22 Oct '14

A long, boring, letter/whitepaper discussing what we might do to support distributed transactions is attached. Please weigh in. Thanks. --Lee

1 0