Hi -
Cool!
I'm unfamiliar with GlusterFS but looking at Wikipedia it appears
that it's typically deployed to separate HW (i.e. there are storage
servers). Compare with HDFS, which to my understanding at least, is
typically deployed across all the nodes, and those nodes also perform
"compute" jobs.
Anyway, that implies to me that GlusterFS should be more like our
Lustre support - in that it might be beneficial to be aware of file
striping, but that there is generally not action the Chapel modules/runtime
could take to run some code closer to the data.
At the same type, poking around online, it seems that GlusterFS+striping
may be an unusual configuration. I found online materials that
indicate that the default stripe block size is 128KB and that
the volfile can include cluster.stripe-block-size to change that.
At the same time, our default block size with QIO is 64KB right now.
So, if that information is correct, a configuration that didn't
pay any particular attention to striping would probably perform OK
out of the box.
So - here is what I see as the path forward:
1) build a way to access a GlusterFS filesystem at all
(drawing from either HDFS or Lustre support now)
2) make open(url=...) work in some kind of
way that allows the existing aux IO "plugins" to register
URL types (so that hdfs:// -> HDFS, http:// -> Curl,
and presumably something like glusterfs:// -> GlusterFS)
3) extend various Filesystem module functions to be able
to work with an aux IO "plugin". For example, you should
be able to list the files in an HDFS or GlusterFS directory.
I'd expect this to be achieved by adding more functions
into the QIO function table that already supports things
like read/write/pread/...
4) building any additional support you think is necessary
into a GlusterFS module. This module can call the
GlusterFS support functions directly. Note though that I don't
think that this module necessarily needs to exist at all.
In fact, I hope that it is only necessary for GlusterFS-specific
functionality - meaning that the other strategy (open with url=
and the Filesystem improvements) covers common uses at least.
Cheers,
-michael
On 4/2/16, 10:53 AM, "ct clmsn" <[email protected]> wrote:
>chapel-devs,
>
>
>I've been working on GlusterFS support for Chapel. At the moment, the
>code is based on the HDFS implementation.
>
>
>I'm having a little bit of trouble figuring out how to implement a
>gluster version of hdfs_locales_for_range
>
>
>The gluster-api has a function called glfs_get_volfile which returns
>information about the gluster set up but not any specific information
>about byte-range mappings to hosts.
>
>
>Would a gluster version of hdfs_locales_for_range be a requirement for
>gluster support in the chapel runtime?
>
>
>
>
>Thanks!
>--
>ct
>
>
>BTW: Here's some additional information about glfs_get_volfile:
>http://www.gluster.org/community/documentation/index.php/Understanding_vol
>-file
><http://www.gluster.org/community/documentation/index.php/Understanding_vo
>l-file>
>
>
>
>
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
