April 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

[aesop] #34: Initialization + declaration: invalid reorder
by aesop 30 Sep '14

30 Sep '14

#34: Initialization + declaration: invalid reorder ---------------------------+------------------------------------------------ Reporter: dkimpe | Owner: Type: defect | Status: new Priority: major | Component: code generator Version: git repository | Keywords: ---------------------------+------------------------------------------------ In the following (accepted by the compiler): {{{ ... init_a (); int my_var = call_b (); ... }}} my_var gets moved to the context structure (correct); However, it gets initialized at the beginning of the function, effectively moving {{{call_b}}} before {{{init_a}}} in the example. This can be a very hard to track down bug... Possible solution: disallow behavior in source translator or fix. -- Ticket URL: <https://trac.mcs.anl.gov/projects/aesop/ticket/34> aesop <https://trac.mcs.anl.gov/projects/aesop> The Aesop Language

1 2

[aesop] #26: OSX warnings during build
by aesop 12 Sep '14

12 Sep '14

#26: OSX warnings during build -------------------------------+-------------------------------------------- Reporter: rross@… | Type: defect Status: new | Priority: don't know Component: don't know | Version: Keywords: | -------------------------------+-------------------------------------------- Lots of warnings when building on my OSX box. -- Rob --- make -C src/c-utils GHC parser/ae-blocking-parser CC opcache.o CC aesop.o DEP lookup3.d DEP triton-string.d CC resource.o DEP libev/event.d In file included from ../resource.c:1: ../src/c-utils/libev/ev.h: In function ‘ev_default_loop_uc_’: ../src/c-utils/libev/ev.h:548: warning: nested extern declaration of ‘ev_default_loop_ptr’ DEP libev/ev.d ../resource.c: In function ‘ae_get_stack’: ../resource.c:738: warning: format not a string literal and no format arguments CC hints.o CC libev/ev.o CC libev/event.o CC triton-string.o CC lookup3.o CC ae-ctl.o CC ae-init.o RANLIB libc-utils.a Linking parser/ae-blocking-parser ... ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame AECC src/aefile/aefile.ae AECC src/socket/aesocket.ae AECC resources/resourcebuilder/resourcebuilder.hae AECC resources/thread/aethread.hae AECC resources/timer/timer.hae CC resources/resourcebuilder/resourcebuilder.o CC resources/thread/aethread.o CC resources/timer/timer.o In file included from ../resources/timer/timer.c:14: ../src/c-utils/libev/ev.h: In function ‘ev_default_loop_uc_’: ../src/c-utils/libev/ev.h:548: warning: nested extern declaration of ‘ev_default_loop_ptr’ /usr/include/assert.h:79: warning: previous declaration of ‘__assert_rtn’ was here /usr/include/assert.h:79: warning: previous declaration of ‘__assert_rtn’ was here ../src/aefile/aefile.hae:23: warning: previous declaration of ‘aefile_pwrite’ was here ../src/aefile/aefile.hae:24: warning: previous declaration of ‘aefile_pread’ was here ../src/aefile/aefile.hae:22: warning: previous declaration of ‘aefile_fsync’ was here ../src/aefile/aefile.hae:23: warning: previous declaration of ‘aefile_fdatasync’ was here ../src/aefile/aefile.ae: In function ‘__ae_worker_aefile_fdatasync’: ../src/aefile/aefile.ae:88: warning: nested extern declaration of ‘fdatasync’ ../src/aefile/aefile.ae: At top level: ../src/aefile/aefile.hae:25: warning: previous declaration of ‘aefile_ftruncate’ was here ../src/aefile/aefile.hae:25: warning: previous declaration of ‘aefile_unlink’ was here /usr/include/assert.h:79: warning: previous declaration of ‘__assert_rtn’ was here /usr/include/assert.h:79: warning: previous declaration of ‘__assert_rtn’ was here /usr/include/string.h:172: warning: previous declaration of ‘swab’ was here /usr/include/stdlib.h:218: warning: previous declaration of ‘mkstemp’ was here /usr/include/stdlib.h:217: warning: previous declaration of ‘mktemp’ was here /usr/include/stdlib.h:235: warning: previous declaration of ‘setkey’ was here /usr/include/stdlib.h:341: warning: previous declaration of ‘valloc’ was here /usr/include/stdlib.h:340: warning: previous declaration of ‘suboptarg’ was here /usr/include/stdlib.h:206: warning: previous declaration of ‘getsubopt’ was here /usr/include/assert.h:79: warning: previous declaration of ‘__assert_rtn’ was here /usr/include/pthread.h:400: warning: previous declaration of ‘pthread_kill’ was here /usr/include/pthread.h:406: warning: previous declaration of ‘pthread_sigmask’ was here /usr/include/unistd.h:710: warning: previous declaration of ‘mknod’ was here ../src/c-utils/libev/ev.h: In function ‘ev_default_loop_uc_’: ../src/c-utils/libev/ev.h:548: warning: nested extern declaration of ‘ev_default_loop_ptr’ ../src/socket/aesocket.ae: At top level: ../src/socket/aesocket.hae:79: warning: previous declaration of ‘aesocket_ready’ was here ../src/socket/aesocket.hae:45: warning: previous declaration of ‘aesocket_accept’ was here ../src/socket/aesocket.hae:56: warning: previous declaration of ‘aesocket_read’ was here ../src/socket/aesocket.hae:67: warning: previous declaration of ‘aesocket_write’ was here RANLIB lib/libaesop.a mcswl174:build rross$ -- Ticket URL: <http://trac.mcs.anl.gov/projects/aesop/ticket/26> aesop <https://trac.mcs.anl.gov/projects/aesop> The Aesop Language

1 1

[aesop] #22: overriding CFLAGS in make or configure causes build to fail.
by aesop 12 Sep '14

12 Sep '14

#22: overriding CFLAGS in make or configure causes build to fail. ---------------------------+------------------------------------------------ Reporter: dkimpe | Owner: Type: defect | Status: new Priority: minor | Component: build system Version: git repository | Keywords: ---------------------------+------------------------------------------------ Configuring aesop using CFLAGS="-O2" (i.e. ./configure CFLAGS="-O2") or issuing make CFLAGS="-O2" causes the build to fail. One reason is that it overrides the -I needed to find aesop.h. This most likely is a bug in Makefile.in and/or aecc -- Ticket URL: <http://trac.mcs.anl.gov/projects/aesop/ticket/22> aesop <https://trac.mcs.anl.gov/projects/aesop> The Aesop Language

1 2

Weekly report
by guoxinl＠clemson.edu 16 Jun '14

16 Jun '14

Dear all, In this week, we analyzed the test results of a proximity-aware file replication method, which copies data to the hubs of all request paths in a P2P file storage. We compared the performance with other methods, which replicates files onto client-side, server-side and hot paths. In this week, we will study a replication method based on a hybrid structure with both structured and unstructured P2P overlay in order to achieve a better tradeoff between replication overhead and request latencies. Guoxin Liu PHD Candidate ECE, Clemson University

2 2

Re: [ASG] [EXTERNAL] Re: Client API discussion
by Phil Carns 30 Apr '14

30 Apr '14

On 04/01/2014 12:42 AM, Ross, Robert B. wrote: > I havenï¿½t seen follow-up on this, so I will open a long-standing can of worms. > > I believe that (2) is a server API thing, and ASG (as a thing we are trying to share) is a service API and not a server API. > > Rob > > On Mar 27, 2014, at 11:34 AM, Ward, Lee <lee(a)sandia.gov> wrote: > >> Unreal. I totally forgot about this when preparing for my recent travels. Apologies. >> >> Thank you for the nice discussion. I did have a couple of related topics in my notes that I wanted to bring up. How might we discuss those? >> >> They wereï¿½. >> >> 1) Batches and transactions. We have an API and set of semantics for this. I am not entirely comfortable with our distributed transaction support and need thought and suggestions from the group. This is a belated response, but I was thinking about this again recently in the context of another topic. I don't know if it is helpful, but here are some additional thoughts from the Triton design perspective: The first thing that makes batches/transactions tricky in Triton is that Triton clients don't (generally) have knowledge about what objects are on what servers. We might provide some help in finding unused object IDs that are organized in a helpful way, but beyond that the servers can move things around in response to group membership changes without notifying clients. This is notable because it means that any transaction that spans objects has the potential to be a distributed transaction. The client isn't authoritative in determining if objects are on the same server or not, and it can't force arbitrary objects to move to or stay on a particular server. The second issue is that even transactions that are limited to a single object require special treatment if the object is being replicated in real time (as opposed to deferring replication until a close or a sync). Replicas need to be internally consistent so that it won't matter which one survives a failure or which one is read by a client later. For normal operations, the update IDs solve most of the replica consistency problem by providing a deterministic way to make sure that a given write produces the same result on all replicas. Batches/transactions can make this more complex, though, in particular if the transaction allows for operations that depend on one another (like an atomic read/modify/write). The reason is because the outcome of those transactions (in terms of what ends up on disk) inherently depends on the initial state of the object. If you naively apply the same transaction to all replicas then you have to make sure that they all have the same initial state or else they might produce divergent results. This is doable, but it usually means that you have to serialize operations across replicas. We had a subset of this problem in implementing ASG-style conditional operators in Triton; we couldn't just execute the same conditional write to all replicas because they might not all reach the same decision. Instead we had the master replica authoritatively decide if the conditional would succeed or not and then forward the resulting update to the replicas. This approach was fairly straightforward because we only had to serialize the conditional update id check on the master. We weren't serializing the actual I/O path, and the operations forwarded to replicas were easily derived from the original operation (usually we just forwarded the same operation with a different flag set). Anyway, these are details that are specific to the Triton architecture, but these are the kinds of things that rattle around in my head when we talk about supporting batches and transactions. I think what it boils down to is that Triton is in a design space where any transaction (whether it is to one object, multiple objects on one server, or multiple objects on different servers) would have to be treated as a proper distributed transaction. We can't trust much of anything to be constrained to a single server. -Phil >> 2) Sirocco needs cache validation/invalidation calls. Triton should not need this but probably can accommodate the API without issue. Check with ANL on that! >> >> These were notes to self and item 2 needs some explanation. We think we need to be able to have a client tell a server that it should believe it is authoritative for a container+object and, similarly, that it should no longer believe it is if it already thinks it is. This is fallout from our free movement of data model. In essence we need a way for the client to promise one or more servers that it is making coherent and consistent updates so that the server is not required to search the system on each read request for the highest update ID. Similarly, the client needs to tell a server it has (or will immediately) make changes to an object that are (will be) not visible to the server. This raises an issue in that we need some way to restrict this idea of authority about the contents of an object to a coherence group made of cooperating clients. >> >> The "check with ANL" part is that I'm thinking the relevant Triton servers are always authoritative and can simply ignore the calls. Yes? If so, should the Triton server just say OK or return an error saying OK for the "become authoritative" call and return something like "not supported" for the invalidate call? >> >> Thanks and sorry again. >> >> --Lee >> >> On Mar 19, 2014, at 9:59 AM, Rob Ross wrote: >> >>> Hi Matthew, thanks for the response, more replies inline. ï¿½ Rob >>> >>> On Mar 18, 2014, at 3:29 PM, Curry, Matthew Leon <mlcurry(a)SANDIA.GOV> wrote: >>>> On 3/18/14, 11:17 AM, "Rob Ross" <rross(a)mcs.anl.gov> wrote: >>>>> On Mar 17, 2014, at 5:10 PM, Harms, Kevin N. <harms(a)alcf.anl.gov> wrote: >>> [ snip ] >>> >>>>>> == Read + Probe == >>>>>> ==== Issue ==== >>>>>> * race of contents changing between probe and read >>>>>> ==== Discussion ==== >>>>>> * versions may change between probe and read >>>>>> * solve with batch that enforces isolation >>>>>> ** (Phil) ASG was system API but batch is only for per-server which >>>>>> alters API usage >>>>>> * one solution with no isolation is probe+read in a single command >>>>>> * local transaction for a single server might be useful for this >>>>>> * Can this be used to make a consistent duplicate? (cloning) >>>>>> ==== Decision ==== >>>>>> * Update asg_read call to add ï¿½probe for recordï¿½ parameters (may >>>>>> specify NULL if you donï¿½t want the probe data) >>>>>> * No change needed to support multiple probes, just always start at n+1 >>>>>> from previous returned call >>>>>> ==== Issue ==== >>>>>> * how to handle need to make multiple probe calls, if you can't return >>>>>> all results in one call. >>>>>> ==== Decision ==== >>>>>> * no change needed >>>>>> ** always probe (n+1) >>>>> Is this describing a mechanism for iterating through results of a probe >>>>> call? If so, is some sort of cookie or something passed around with the >>>>> call that enables the state to be serialized and not require tracking of >>>>> clients? Assumption is that since the probe is relative to some >>>>> update_id, results donï¿½t change (which would otherwise make things v. >>>>> hard)? >>>> This is describing how to iterate a probe when there are other servers >>>> inserting entries into the address space. The probe call does return the >>>> offset of the next record, but if another server were to insert something >>>> in the address space between the end of the last probe and the start of >>>> the next one, the server doing the probe would completely skip that >>>> insertion. It was decided that, if the server really cared about that use >>>> case, it could ignore the ï¿½next offsetï¿½ return value from the probe, and >>>> just probe from just beyond the end of the last interval it got. >>>> >>>> Can you clarify what you mean by ï¿½probe is relative to some update_idï¿½? >>> Thanks. I read the header, so I am more informed now :). We should note somewhere what the instance_ids are for. >>> >>> We say that we do not ï¿½create a snapshotï¿½ with probe(s), and there is no update_id associated with a given container/object/fork for a user to use to reason about that set of changes they can perform while a probe is occurring (e.g., if I use larger update_ids while I write to this, I can probe on earlier ones and know I will get sane results). >>> >>> In PVFS we passed back a token that we used to avoid having to search to a specific ID, with the problem that changes to the thing we were iterating over (usually a directory) might result in duplicates in the output, etc. In the solution here we will need to search for the next ID each time, so every probe will incur a search (could be fast or slow, depending, obviously). If the use case is to iterate through all the things in a big set, then this could be high overhead as compared to a ï¿½give me back an iterator tokenï¿½, but the iterator approach is flawed unless you have some way of creating an instance over which you can iterate and know you arenï¿½t missing anything. >>> >>> Anyway, I donï¿½t really have a suggestion on this front, just wanted to say that this is going to be a point of complexity for users. >>> >>>>>> ==== Decision ==== >>>>>> * Switch to ï¿½update_idï¿½ instead of version_id in ASG documentation >>>>>> >>>>>> == Multiple Round-Trips for Probes and Reads == >>>>>> ==== Issue ==== >>>>>> * a large discontiguous file could result in requiring many probe+reads >>>>>> ==== Discussion ==== >>>>>> * (Matt) use probe+read, donï¿½t ask for probe results and zero-fill data >>>>>> (assume 1 byte records with zero value) >>>>>> * (Dries) have a method to request default record behavior (so for >>>>>> zero-fill, ask for default of 1-byte zero records) (requires storing >>>>>> this metadata with object/fork/etc) >>>>>> * (Dries) possible uses for security implementation >>>>>> ==== Decision ==== >>>>>> * none >>>>> Are we really proposing a fill capability on the object server side (and >>>>> thus some semantic about filling records in order), or is this more about >>>>> an ability to have the server create ï¿½virtualï¿½ records that enable us to >>>>> make more efficient requests? >>>> This one deserves a little motivation. I was concerned about doing file >>>> I/O in cases where objects have random writes and/or lots of holes. Just >>>> by virtue of incrementing update_ids, you get into a situation where the >>>> probe data may very well be larger than the data youï¿½re reading. There >>>> were two solutions that were briefly discussed, and one that wasnï¿½t: >>>> 1. (Admittedly the weakest) Use zero fill on the server side to obviate >>>> the need for an accompanying probe. Dries suggested the alternative of >>>> allowing the client to set the default record. A flag would be used to >>>> dictate whether fill could be used, and the server could send whichever >>>> representation would be smaller. (see item 3 below) >>>> 2. Allow probes to accept a flag that said that update_ids arenï¿½t >>>> important, so a single record could be used for dense data with various >>>> record IDs and homogeneous record size. Better, but does not cover the >>>> case where there are lots of holes. >>>> 3. (The one I didnï¿½t bring up yet, because itï¿½s weird.) Allow a single >>>> buffer space to contain probe and read contents. Having separate buffers >>>> can cause the probe buffer to fill well before the read, giving us a lot >>>> of data that doesnï¿½t have a proper map for detecting holes or differently >>>> sized records, necessitating a reread. This ties into probe+read, which >>>> Iï¿½ll talk about next. >>>> >>>>> Are we really happy with this probe+read approach? Seems like weï¿½re >>>>> driving down a path to multiple operations when we only want one. What am >>>>> I missing? >>>> Dries (and Lee, privately, about a month ago) proposed a combined >>>> probe+read operation that does both with one call. Driesï¿½s idea of the >>>> signature is similar to: >>>> >>>> int asg_probe_read ( >>>> asg_instance_t instance, >>>> asg_location_t location, >>>> asg_container_id_t container, >>>> asg_object_id_t object, >>>> asg_fork_id_t fork, >>>> asg_record_id_t start_record, >>>> asg_size_t recordcount, >>>> asg_flags_t flags, >>>> asg_version_t version_condition, >>>> void * readbuf, >>>> size_t readbufsize, >>>> >>>> asg_record_info_t * probebuf, >>>> size_t probebufsize, >>>> asg_size_t * transferred); >>>> >>>> You can do a plain read by passing probebuf=NULL, and you can do a plain >>>> probe by passing readbuf=NULL. >>> I assume this is really asg_probe_read_fork() and that what you get back is the results of the probe plus the data from the matches? >>> >>> It sounds like you worked out the use case of reading from a sparse fork that one would expect in the ï¿½Iï¿½m using an object to hold the data for a shard of a POSIX file, using single byte recordsï¿½. I assume the above lets me say ï¿½give me all the data in this rangeï¿½ and I get back some data plus a list of what regions they correspond to, which should be a win 99% of the time (e.g., except in cases where someone wrote every other byte, or something similarly gnarly)? >>> >>> [ snip ] >>> >>>>>> == Can update_id decrease (or is it allowed to)? == >>>>>> ==== Issue ==== >>>>>> * Should we allow a decreasing update_id? >>>>>> ==== Discussion ==== >>>>>> * no one had a good reason to support this outside of reset >>>>>> ==== Decision ==== >>>>>> * do not allow reducing update_id, other than via reset and reset >>>>>> always goes to update_id = zero >>>>>> * May use same update_id on write >>>>>> * Zero is not a valid update_id to write >>>>> So clients have to coordinate if writing to multiple update_ids >>>>> concurrently, or they will get an error? Surely I am misunderstanding. >>>>> What does it mean to ï¿½decreaseï¿½ an update_id? >>>> ï¿½Decreasing an update_idï¿½ is overwriting one or more records on a server >>>> with an update_id that is lower than those records already have. The >>>> reason for striking this was that Sirocco has problems doing that, because >>>> decreasing an update_id harms reconciling objects when thereï¿½s a mismatch. >>>> The only way to keep that lower-update overwrite is extremely expensive >>>> and may not always work. >>> Ok, so specifically if someone writes to a record and specified an update_id lower than the current one, then they will get an error writing (or is it undefined?). Thus it is up to a user to coordinate updates at the record level. Makes sense. Thanks. >>> >>>>>> == Security Capabilities == >>>>>> ==== Issue ==== >>>>>> * how to integrate security into ASG API >>>>>> ==== Discussion ==== >>>>>> * (Dries) separate APIs, just add single capability argument to all >>>>>> other APIs >>>>>> * tabled discussion for now since it is not needed at this time >>>>>> >>>>>> == Nesting of IDs in Sirocco == >>>>>> ==== Issue ==== >>>>>> * Sirocco allows generic nesting of ID spaces in the local store API, >>>>>> should this be extended to ASG? >>>>>> ==== Discussion ==== >>>>>> * any level of ID may store data >>>>>> * new API probe_child (which gives details about lower levels) >>>>>> * new API probe_data (which only gives data) >>>> Iï¿½d like to add that my argument against extending the ID space was >>>> because we wanted to have some address space available for the server to >>>> use for its own purposes, that the client shouldnï¿½t be able to access. I >>>> think thatï¿½s the primary reason we didnï¿½t propose. >>> This can be done at the server level, as you say. >>> >>> Thanks for the detailed and thoughtful responses. >>> >>> Rob >>> _______________________________________________ >>> ASG mailing list >>> ASG(a)lists.mcs.anl.gov >>> https://lists.mcs.anl.gov/mailman/listinfo/asg > _______________________________________________ > ASG mailing list > ASG(a)lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/asg

1 0

weekly update
by jingxuan 28 Apr '14

28 Apr '14

Hi, everyone, last week, I have integrated my prototype code between clients and authorization server based on mercury mode SSM, added capabilities cache and search process in clients and debugged successfully, after this week’s final exam, we could begin our prototype testing. Jingxuan SUN Holcombe Department of Electrical and Computer Engineering Clemson University Tel:864-643-8210 Email: jingxus(a)g.clemson.edu

1 0

UAB Status
by Alex Filby 28 Apr '14

28 Apr '14

All, Last week UAB transferred Seok's responsibilities to Shane and myself to prepare for his imminent departure and continued to work on a new release candidate. Thanks, Alex Filby

1 0

TAMU status update
by Gim Jongmin 28 Apr '14

28 Apr '14

Dear All, We are writing a code for newly designed directory cache structure. Our effort to metadata operation overhead is focused on reducing computation overhead caused by hashing and message exchange overhead between client/server. Especially, we found that version checking routine for all files in a given directory makes metadata overhead to be increased exponentially, and this new design applies one of solution choice. Sincerely, Jongmin -- Jongmin Gim Post-Doctoral Research Associate Dept. of Elecrical and Computer Enginerring Texas A&M University 333D Wisenbaker College Station, TX 77843-3259 Phone: 979-587-8311

1 0