Mike,
Great! I'll start looking into the Lustre support and see if there's more
of an intersection with that implementation. GlusterFS really advocates
their fuse support but I noticed there is hadoop/hdfs-gluster
plugin...that's where the idea of using the gluster-api started. Thanks for
taking time for the lit-review and putting together a roadmap.
--
Chris
On Mon, Apr 11, 2016 at 9:19 AM, Michael Ferguson <[email protected]>
wrote:
> 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!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
