Re: [Gluster-devel] CFP for Gluster Developer Summit
Here's my proposal: Title: GFProxy: Scaling the GlusterFS FUSE Client Theme: Experience / (Process & Infrastructure) I plan to cover the following topics: - Discuss the benefits of the FUSE client vs. NFS & how we use it @ Facebook today - Discuss scalability challenges with the FUSE client, operational overhead, etc. - Introduce GFProxy: - Splitting the core parts of the fuse client (DHT + AFR) into a separate daemon, which effectively acts as a proxy between FUSE clients and bricks - Managing failover in the GFProxy FUSE Client with the AHA (Advanced High Availability) xlator - Current deployment & code status (hope to get this upstream soon!) > On Aug 12, 2016, at 12:48 PM, Vijay Bellur wrote: > > Hey All, > > Gluster Developer Summit 2016 is fast approaching [1] on us. We are looking > to have talks and discussions related to the following themes in the summit: > > 1. Gluster.Next - focusing on features shaping the future of Gluster > > 2. Experience - Description of real world experience and feedback from: > a> Devops and Users deploying Gluster in production > b> Developers integrating Gluster with other ecosystems > > 3. Use cases - focusing on key use cases that drive Gluster.today and > Gluster.Next > > 4. Stability & Performance - focusing on current improvements to reduce our > technical debt backlog > > 5. Process & infrastructure - focusing on improving current workflow, > infrastructure to make life easier for all of us! > > If you have a talk/discussion proposal that can be part of these themes, > please send out your proposal(s) by replying to this thread. Please clearly > mention the theme for which your proposal is relevant when you do so. We will > be ending the CFP by 12 midnight PDT on August 31st, 2016. > > If you have other topics that do not fit in the themes listed, please feel > free to propose and we might be able to accommodate some of them as > lightening talks or something similar. > > Please do reach out to me or Amye if you have any questions. > > Thanks! > Vijay > > [1] > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.gluster.org_events_summit2016_&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=N7LE2BKIHDDBvkYkakYthA&m=YY6RlpXtmezdNewpKyfYyGENFYgjRPKwC74nWCvnYpg&s=4R3BxJ2a-DiwEIMB2xOQMrKRlA7jw3cy7dYuz-uA6Eg&e= > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gluster.org_mailman_listinfo_gluster-2Ddevel&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=N7LE2BKIHDDBvkYkakYthA&m=YY6RlpXtmezdNewpKyfYyGENFYgjRPKwC74nWCvnYpg&s=fkgZ0Bm8lrwHWwBw8PNpeCoEba4KZUyh7IpjBKZ3pqc&e= > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Gluster Summit 2016
Thanks for the info! On Mar 21, 2016, at 8:58 PM, Amye Scavarda mailto:a...@redhat.com>> wrote: Hey there! We're currently tracking for October on this around LinuxCon Berlin. Nothing's official yet, but that's the current timeline. Does that help? - amye On Mon, Mar 21, 2016 at 6:42 PM, Shreyas Siravara mailto:sshre...@fb.com>> wrote: Hey guys, Any news on the timeline for this years Gluster Summit? Just trying to plan ahead ... :) Shreyas ___ Gluster-devel mailing list Gluster-devel@gluster.org<mailto:Gluster-devel@gluster.org> http://www.gluster.org/mailman/listinfo/gluster-devel<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gluster.org_mailman_listinfo_gluster-2Ddevel&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=N7LE2BKIHDDBvkYkakYthA&m=nIXKu7rQKgGnR--Bw7ZdJ9E3lf0eN13SrCpnwBLrdeQ&s=8idaBoT2WwxsB2MdCm-tAFrT6dw4j9nfJRhJjCTR4kU&e=> -- Amye Scavarda | a...@redhat.com<mailto:a...@redhat.com> | Gluster Community Lead ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Gluster Summit 2016
Hey guys, Any news on the timeline for this years Gluster Summit? Just trying to plan ahead ... :) Shreyas ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Throttling xlator on the bricks
So the way our throttling works is (intentionally) very simplistic. (1) When someone mounts an NFS share, we tag the frame with a 32 bit hash of the export name they were authorized to mount. (2) io-stats keeps track of the "current rate" of fops we're seeing for that particular mount, using a sampling of fops and a moving average over a short period of time. (3) Based on whether the share violated its allowed rate (which is defined in a config file), we tag the FOP as "least-pri". Of course this makes the assumption that all NFS endpoints are receiving roughly the same # of FOPs. The rate defined in the config file is a *per* NFS endpoint number. So if your cluster has 10 NFS endpoints, and you've pre-computed that it can do roughly 1000 FOPs per second, the rate in the config file would be 100. (4) IO-Threads then shoves the FOP into the least-pri queue, rather than its default. The value is honored all the way down to the bricks. The code is actually complete, and I'll put it up for review after we iron out a few minor issues. > On Jan 27, 2016, at 9:48 PM, Ravishankar N wrote: > > On 01/26/2016 08:41 AM, Richard Wareing wrote: >> In any event, it might be worth having Shreyas detail his throttling feature >> (that can throttle any directory hierarchy no less) to illustrate how a >> simpler design can achieve similar results to these more complicated (and it >> followsbug prone) approaches. >> >> Richard > Hi Shreyas, > > Wondering if you can share the details of the throttling feature you're > working on. Even if there's no code, a description of what it is trying to > achieve and how will be great. > > Thanks, > Ravi ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Throttling xlator on the bricks
Just out of curiosity, what benefits do we think this throttling xlator would provide over the "enable-least-priority" option (where we put all the fops from SHD, etc into a least pri queue)? > On Jan 25, 2016, at 12:29 AM, Venky Shankar wrote: > > On Mon, Jan 25, 2016 at 01:08:38PM +0530, Ravishankar N wrote: >> On 01/25/2016 12:56 PM, Venky Shankar wrote: >>> Also, it would be beneficial to have the core TBF implementation as part of >>> libglusterfs so as to be consumable by the server side xlator component to >>> throttle dispatched FOPs and for daemons to throttle anything that's outside >>> "brick" boundary (such as cpu, etc..). >> That makes sense. We were initially thinking to overload posix_rchecksum() >> to do the SHA256 sums for the signer. > > That does have advantages by avoiding network rountrips by computing SHA* > locally. > TBF could still implement ->rchecksum and throttle that (on behalf of clients, > residing on the server - internal daemons). Placing the core implementation as > part of libglusterfs would still provide the flexibility. > >> >> > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gluster.org_mailman_listinfo_gluster-2Ddevel&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=N7LE2BKIHDDBvkYkakYthA&m=9W9xtRg0TIEUvFL-8HpUCux8psoWKkUbEFiwqykRwH4&s=OVF0dZRXt8GFcIxsHlkbNjH-bjD9097q5hjVVHgOFkQ&e= > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
