Hi all, In case anyone is interested, an initial cut at an ASG backend for the IOR benchmark is now available in this repo: git clone [email protected]:asg/ior Some notes are in the README.ASG file at the top level. It's not a complete implementation by any means, but it is enough to at least run some very simple configurations. The documentation and autoconf logic only shows how to link it against Triton, but in theory it could be linked to any ASG implementation with minimal change. The code is based directly off of the IOR tree from github and I did not make any changes to the core logic. The ASG back end fits in just like any of the other IOR back ends alongside posix, mpiio, pnetcdf, and hdf5. Here is an example running it on my laptop. Please ignore the performance of course- my laptop isn't a particularly interesting HPC platform :) # start a server $ ./triton-server --conf ~/triton-confs/1.conf --listenaddr tcp://localhost:3344 [14:25:23.603714 info]: Server using configuration file /home/pcarns/triton-confs/1.conf # confirm an empty Triton storage system $ ./triton-ls tcp://localhost:3344 Objects on server ::3344 (tcp://localhost:3344): # run IOR, file-per-proc mode, 128 MiB total per node, 16 MiB access size, write only $ mpiexec -n 4 ./ior -f ~/triton-confs/ior-uniq.conf > ior-output.log Commencing write performance test: Tue Jun 10 14:25:53 2014 WARNING: ASG aiori cannot properly confirm object size yet. # check performance $ grep "Max Write" ior-output.log Max Write: 124.02 MiB/sec (130.04 MB/sec) # confirm that 4 objects were written $ ./triton-ls tcp://localhost:3344 Objects on server ::3344 (tcp://localhost:3344): 1341:88ea:cf70:fc57::1 1341:88ea:cf70:fc58::1 1341:88ea:cf70:fc59::1 1341:88ea:cf70:fc5a::1 # check the underlying storage too $ ls -alh /tmp/triton-server-tcp\:localhost\:3344-data/ total 517M drwxr-xr-x 2 pcarns pcarns 4.0K Jun 10 14:25 . drwxrwxrwt 17 root root 4.3M Jun 10 14:26 .. -rw------- 1 pcarns pcarns 129M Jun 10 14:25 1341:88ea:cf70:fc57::1.dat -rw------- 1 pcarns pcarns 129M Jun 10 14:25 1341:88ea:cf70:fc58::1.dat -rw------- 1 pcarns pcarns 129M Jun 10 14:25 1341:88ea:cf70:fc59::1.dat -rw------- 1 pcarns pcarns 129M Jun 10 14:25 1341:88ea:cf70:fc5a::1.dat The file names are mapped to objects by hashing them (using a simplistic hash; the IDs tend to be bunched up as you can see above), and the "create" and "close" steps don't actually do much of anything except attach to the storage system. I have not filled in read or size checking logic. I'll work on filling in more of the implementation as time permits; I just wanted to share what I have so far. This code might also suggest some gaps in our API. There are a few IOR features that don't easily map to ASG functionality. We'll try to keep track of those; this might be a reasonable test platform for some API extension experiments at some point. thanks, -Phil