Re: [Gluster-users] [Gluster-devel] Chaning position of md-cache in xlator graph
On Tue, Oct 21, 2014 at 2:58 AM, Raghavendra Gowdappa wrote: > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1138970 Posted a comment in the BZ ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
[Gluster-users] Todays Gluster Bug Triage meeting minutes
On Tue, Oct 21, 2014 at 10:05:59AM +0200, Niels de Vos wrote: > Hi all, > > please join the #gluster-meeting IRC channel on irc.freenode.net to > participate on the following topics: > > * Roll call > * Status of last weeks action items > * Add distinction between "problem reports" and "enhancement requests" > * Group Triage > * Open Floor > > More details on the above, and last minute changes to the agenda are > kept in the etherpad for this meeting: > - https://public.pad.fsfe.org/p/gluster-bug-triage > > The meeting starts at 12:00 UTC, you can convert that to your own > timezone with the 'date' command: > > $ date -d "12:00 UTC" > > Cheers, > Niels We've discussed quite some topics again today. IRC logs are here: Minutes: http://meetbot.fedoraproject.org/gluster-meeting/2014-10-21/gluster-meeting.2014-10-21-12.00.html Minutes (text): http://meetbot.fedoraproject.org/gluster-meeting/2014-10-21/gluster-meeting.2014-10-21-12.00.txt Log: http://meetbot.fedoraproject.org/gluster-meeting/2014-10-21/gluster-meeting.2014-10-21-12.00.log.html Next week, there is an other Bug Traige meeting. Anyone is welcome to join and discuss the topics that will land on the agenda. Cheers, Niels The summary of the meeting: * Roll Call (ndevos, 12:01:23) * Status of last weeks action items (ndevos, 12:04:24) * hchiramm to make sure that b...@gluster.org becomes the default owner of new bugs (ndevos, 12:04:53) * ACTION: Humble checks with the Bugzilla team if b...@gluster.org can become the default owner of bugs (ndevos, 12:06:00) * hchiramm will split the Bug Triage page into smaller ones, starting with a "How to clone" best practise (ndevos, 12:06:05) * LINK: http://www.gluster.org/community/documentation/index.php/Bug_triage is the big page that could become smaller (ndevos, 12:07:10) * ACTION: lalatenduM will think about splitting the "Bug Triage" wiki page, and make suggestions later (ndevos, 12:10:04) * hchiramm_ to include a suggestion to assign a clone of a bug (and keep/add b...@gluster.org on CC) in his 'how to clone' steps (ndevos, 12:10:21) * Humble and ndevos will figure out how to get "a report on how many bugs exist in each version of glusterfs (ndevos, 12:14:53) * AGREED: http://goo.gl/IA7zaq is a useful report for the number of bugs per Gluster version (ndevos, 12:18:27) * EVERYONE to review http://www.gluster.org/community/documentation/index.php/How_to_clone and give feedback to Humble, or update the page themselves (ndevos, 12:23:56) * AGREED: The "How to clone" wiki page should be fine as it is (ndevos, 12:27:55) * hagarth will look for somebody that can act like a bug assigner manager kind of person (ndevos, 12:27:59) * ACTION: hagarth will look for somebody that can act like a bug assigner manager kind of person (ndevos, 12:28:27) * pranithk to report how his team is assigning triaged bugs (ndevos, 12:28:42) * LINK: http://www.gluster.org/community/documentation/index.php/Bugzilla_Notifications#RSS_Feeds (ndevos, 12:31:17) * Add distinction between "problem reports" and "enhancement requests" (ndevos, 12:38:50) * LINK: http://supercolony.gluster.org/pipermail/gluster-devel/2014-October/042569.html for [FEAT] 'tag' or FutureFeature keyword (ndevos, 12:39:06) * AGREED: leave the email for 'FutureFeature' keyword or '[FEAT]' open for a few days (ndevos, 12:42:05) * Group Triage (ndevos, 12:42:33) * bugs files since last week (ndevos, 12:44:52) * LINK: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&chfield=[Bug creation]&chfieldfrom=-1w&chfieldto=Now&f1=keywords&o1=notsubstring&product=GlusterFS&v1=Triaged (ndevos, 12:44:57) * Open Floor (ndevos, 12:56:23) * LINK: http://gluster.org/mailman/listinfo/bugs -> link to subscribe (Humble, 13:09:06) Meeting ended at 13:13:06 UTC. ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] geo-replication breaks on CentOS 6.5 + gluster 3.6.0 beta3
- Original Message - > I can add do it. I need some time (we have long weekend coming up in > India for Diwali) and some help from Aravinda. Thanks Vishwanath, that will really help. :) Regards and best wishes, Justin Clift -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] geo-replication breaks on CentOS 6.5 + gluster 3.6.0 beta3
On 20/10/14 21:48, Justin Clift wrote: - Original Message - The solution involves "changelog crash consistency" among other things. Since this feature itself is targeted for glusterfs-3.7, I would say the complete solution would be available with glusterfs-3.7 One the major challenges in solving it involves ordering/sequencing the fops that happen on the master volume. Because of the distributed nature of glusterfs and geo-rep, coordinating between gsyncds for proper ordering of fops is hard. I have cc'd Aravinda who is the maintainer of geo-rep. He would have more details. Thanks. :) In the meantime, who is the right person to update our geo-rep docs to include the gotchas, so people know to avoid them? I can add do it. I need some time (we have long weekend coming up in India for Diwali) and some help from Aravinda. Best Regards, Vishwanath + Justin ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] Jumbo frames
- Original Message - > From: "Gene Liverman" > To: "Jean R. Franco" > Cc: "gluster-users" > Sent: Tuesday, October 21, 2014 7:22:14 AM > Subject: Re: [Gluster-users] Jumbo frames > > > > Personally, I think all replication benefits from a 9000 MTU. Bigger frame > equals faster replication. Yep, setting jumbo frames one of the easiest and biggest perf gains you can tune with glusterfs. I don't have any data handy for 1GB NICs but here is something on 10G: http://rhsummit.files.wordpress.com/2012/03/england-rhs-performance.pdf -b > -- > Gene Liverman > Systems Administrator > Information Technology Services > University of West Georgia > glive...@westga.edu > > > ITS: Making Technology Work for You! > > > This e-mail and any attachments may contain confidential and privileged > information. If you are not the intended recipient, please notify the sender > immediately by return mail, delete this message, and destroy any copies. Any > dissemination or use of this information by a person other than the intended > recipient is unauthorized and may be illegal or actionable by law. > On Oct 21, 2014 6:26 AM, "Jean R. Franco" < jfra...@maila.net.br > wrote: > > > > Dear all, > > We're using Huawei's S5300 manageable switches in our deployment. > Would we benefit from higher size jumbo frames? > Right now it's set at 1600. > > Many thanks, > > Jean > > ___ > Gluster-users mailing list > Gluster-users@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users > > ___ > Gluster-users mailing list > Gluster-users@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] how to restrict client connection to server to only one IP address
> Are there any schedules when the GlusterFS 4.0 should become available? Nope. "GlusterFS 4.0" is barely more than a research project right now. To avoid conflict with the more practically oriented 3.7+ work, there's no set schedule. For anyone who's interested, the current "vision" is at the following horrid link: https://docs.google.com/document/d/1BRO_wv8xomPJ2NGFF9DvxXGiKkJzhZqb6wSqpSW_uDI/edit?usp=sharing > If someone is looking how to "fool" the servers and clients there is a > solution here (using /etc/hosts): > http://andreas-lehr.com/blog/archives/612-glusterfs-in-multi-home-environments.html Very nice. We should probably syndicate this on gluster.org or something. Thank you. ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] Jumbo frames
Personally, I think all replication benefits from a 9000 MTU. Bigger frame equals faster replication. -- Gene Liverman Systems Administrator Information Technology Services University of West Georgia glive...@westga.edu ITS: Making Technology Work for You! This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return mail, delete this message, and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal or actionable by law. On Oct 21, 2014 6:26 AM, "Jean R. Franco" wrote: > Dear all, > > We're using Huawei's S5300 manageable switches in our deployment. > Would we benefit from higher size jumbo frames? > Right now it's set at 1600. > > Many thanks, > > Jean > > ___ > Gluster-users mailing list > Gluster-users@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users > ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
[Gluster-users] Jumbo frames
Dear all, We're using Huawei's S5300 manageable switches in our deployment. Would we benefit from higher size jumbo frames? Right now it's set at 1600. Many thanks, Jean ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] Chaning position of md-cache in xlator graph
Adding correct gluster-devel mail id. - Original Message - > From: "Raghavendra Gowdappa" > To: "gluster-devel" > Sent: Tuesday, 21 October, 2014 3:26:21 PM > Subject: Chaning position of md-cache in xlator graph > > Hi all, > > The context is bz 1138970 [1]. As discussed in the bug, it would make more > sense loading md-cache closer to bricks (as a descendant of write-behind to > be specific) from the point of correctness, since stats are affected by > writes. Does anyone of you see any issue in doing this? > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1138970 > > regards, > Raghavendra. ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] Chaning position of md-cache in xlator graph
+ gluster-users - Original Message - > From: "Raghavendra Gowdappa" > To: "gluster-devel" > Sent: Tuesday, 21 October, 2014 3:26:21 PM > Subject: Chaning position of md-cache in xlator graph > > Hi all, > > The context is bz 1138970 [1]. As discussed in the bug, it would make more > sense loading md-cache closer to bricks (as a descendant of write-behind to > be specific) from the point of correctness, since stats are affected by > writes. Does anyone of you see any issue in doing this? > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1138970 > > regards, > Raghavendra. ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] how to restrict client connection to server to only one IP address
W dniu 20.10.2014 22:50, Jeff Darcy pisze: 1. If it is using gluster-fuse, what you are trying to do is futile, because the connections are not as you think. The data does not flow from client1 -> gluster1 -> gluster2. The way it really works is that client1 connects directly to both gluster1 and gluster2, and sends the data to both of them at the same time. The only time any volume of data transfers directly from gluster1 to gluster2 is during a heal operation. Unfortunately, gluster does not understand the concept of a separate "storage network" that the servers use to talk to each other. It only has one address, and that address is the one that the clients connect to. Very well put. :) Better multi-network support is something we're thinking about for GlusterFS 4.0; separate "front end" and "back end" networks is an almost trivial subset of that. Are there any schedules when the GlusterFS 4.0 should become available? To be just a bit more precise, GlusterFS is limited to a concept of one *name* for a server. However, that name can resolve to to different addresses in different contexts. If the servers and clients use different name servers or have different /etc/hosts files, then it is possible to split user and internal traffic in some useful ways. There are also ways to achieve the same thing with explicit routing, or with iptables rules. It's pretty easy to get yourself all messed up this way, which is why it's not generally recommended or supported, but it is at least *possible*. If someone is looking how to "fool" the servers and clients there is a solution here (using /etc/hosts): http://andreas-lehr.com/blog/archives/612-glusterfs-in-multi-home-environments.html -- Łukasz Zygmański Uczelniane Centrum Information & Communication InformatyczneTechnology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University Coll. Maximum, pl. Rapackiego 1, 87-100 Torun, Poland tel.: +48 56 611 27 36 fax: +48 56-622-18-50 email: lukasz.zygman...@umk.pl smime.p7s Description: Kryptograficzna sygnatura S/MIME ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
Re: [Gluster-users] how to restrict client connection to server to only one IP address
W dniu 20.10.2014 22:25, Ted Miller pisze: On 10/16/2014 2:48 PM, Łukasz Zygmański wrote: Hello, I am new to this list and new to GlusterFS, so I would be grateful if you could help me. I am trying to do this setup: client1(10.75.2.45) | | MTU 1500 V (10.75.2.41) gluster1gluster2 (10.75.2.43) ---> (10.75.2.44) <--- MTU 9000 In words, I have two glusterfs servers (in replication): gluster1 and gluster2 and a glusterfs client client1. The gluster1 has two network interfaces: 10.75.2.41 and 10.75.2.43. I would like gluster1 to communicate with gluster2 using jumbo frames and connection would be between interfaces 10.75.2.43 and 10.75.2.44. Since the client1 can only use default packet size (MTU 1500) I would like it to connect with gluster1 using only other network interface: 10.75.2.41. Is it possible? At the moment on gluster1 I have: eno16780032: flags=4163 mtu 1500 inet 10.75.2.43 netmask 255.255.255.0 broadcast 10.75.2.255 eno33559296: flags=4163 mtu 1500 inet 10.75.2.41 netmask 255.255.255.0 broadcast 10.75.2.255 and when I mount from client1 using: mount -t glusterfs 10.75.2.41:/vol1 /mnt/glusterfs it still uses connection to 10.75.2.43: # netstat -natup | egrep '(2.41|2.43)' tcp0 0 10.75.2.45:1020 10.75.2.43:49152 ESTABLISHED 10856/glusterfs tcp0 0 10.75.2.45:1022 10.75.2.41:24007 ESTABLISHED 10856/glusterfs Is there a way to restrict communication from client1 to gluster1 using only one IP address: 10.75.2.41? Any help would be much appreciated. Best regards Lukasz PS GlusterFS version on client: glusterfs-3.5.2-1.el7.x86_64 glusterfs-fuse-3.5.2-1.el7.x86_64 GlusterFS version on server: glusterfs-server-3.5.2-1.el7.x86_64 glusterfs-3.5.2-1.el7.x86_64 Since no one has answered this in a few days, I will try to do so, or at least start the process. You do not mention how the client connects. 1. If it is using gluster-fuse, what you are trying to do is futile, because the connections are not as you think. The data does not flow from client1 -> gluster1 -> gluster2. The way it really works is that client1 connects directly to both gluster1 and gluster2, and sends the data to both of them at the same time. The only time any volume of data transfers directly from gluster1 to gluster2 is during a heal operation. Unfortunately, gluster does not understand the concept of a separate "storage network" that the servers use to talk to each other. It only has one address, and that address is the one that the clients connect to. 2. If the client uses NFS, then you have something more like what you drew. The data passes client1 -> gluster1 via NFS, and then gluster1 -> gluster2. I am not using NFS, so I can't help you with if it is possible to have NFS on one network connection and gluster on a different connection, or what is required to accomplish this (if it can be done at all). Ted Miller Thank you very much Ted, at least I now understand how the connection using FUSE client works and it was the connection I had in mind. -- Łukasz Zygmański Uczelniane Centrum Information & Communication InformatyczneTechnology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University Coll. Maximum, pl. Rapackiego 1, 87-100 Torun, Poland tel.: +48 56 611 27 36 fax: +48 56-622-18-50 email: lukasz.zygman...@umk.pl smime.p7s Description: Kryptograficzna sygnatura S/MIME ___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
[Gluster-users] REMINDER: Gluster Bug Triage meeting later today (12:00 UTC)
Hi all, please join the #gluster-meeting IRC channel on irc.freenode.net to participate on the following topics: * Roll call * Status of last weeks action items * Add distinction between "problem reports" and "enhancement requests" * Group Triage * Open Floor More details on the above, and last minute changes to the agenda are kept in the etherpad for this meeting: - https://public.pad.fsfe.org/p/gluster-bug-triage The meeting starts at 12:00 UTC, you can convert that to your own timezone with the 'date' command: $ date -d "12:00 UTC" Cheers, Niels BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Berlin BEGIN:STANDARD DTSTART:16010101T03 TZOFFSETTO:+0100 TZOFFSETFROM:+0200 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU TZNAME:CET END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02 TZOFFSETTO:+0200 TZOFFSETFROM:+0100 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU TZNAME:CEST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:2b343380-48a4-4972-a9e6-6671c536bb97 RRULE:FREQ=WEEKLY;INTERVAL=1 SUMMARY:Gluster Community Bug triage meeting LOCATION:#gluster-meeting on Freenode IRC ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:gluster -de...@gluster.org ATTENDEE;CN=gluster-users@gluster.org;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-AC TION;RSVP=TRUE:mailto:gluster-users@gluster.org ORGANIZER;CN=Niels de Vos:mailto:nde...@redhat.com DTSTART;TZID="Europe/Berlin":20140902T14 DTEND;TZID="Europe/Berlin":20140902T15 STATUS:CONFIRMED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE LAST-MODIFIED:20140829T072226Z DTSTAMP:20140829T072226Z SEQUENCE:0 DESCRIPTION:The following is a new meeting request:\n\nSubject: Gluster Comm unity Bug triage meeting \nOrganiser: "Niels De Vos" \n\ nLocation: #gluster-meeting on Freenode IRC \nTime: 2:00:00 PM - 3:00:00 PM GMT +01:00 Amsterdam\, Berlin\, Bern\, Rome\, Stockholm\, Vienna\n Recurrenc e : Every Tuesday No end date Effective 2 Sep\, 2014\n\nRequired: \nOptiona l: gluster-de...@gluster.org\; gluster-users@gluster.org \n\n*~*~*~*~*~*~*~* ~*~*\n\nHi all\,\n\nin order to improve the quality of GlusterFS we've been discussing about doing\nregular/continuous Bug Triage. As mentioned in an ea rlier email [1] from Lala\,\nwe have hashed out an initial document [2] that explains about Bug Triage and\nwhat it means.\n\nThis meeting is scheduled for anyone that is interested in learning more about\,\nor assisting with th e Bug Triage. All the maintainers of major components that\nare listed in th e MAINTAINERS file [3] are highly encouraged to join.\n\nMeeting details:\n- location: #gluster-meeting on Freenode IRC\n- date: every Tuesday\n- time: 12:00 UTC\, 14:00 CEST\, 14:00 GMT+1 (same as the weekly meeting on Wednesda ys)\n- agenda: https://public.pad.fsfe.org/p/gluster-bug-triage\n\nWe plan t o have these meeting every week\, at least for now. When everyone is\nused t o triage bugs more regularly\, we will increase the interval between the\nme etings.\n\nThanks\,\nNiels\n\n\n[1] http://supercolony.gluster.org/pipermail /gluster-users/2014-August/018488.html\n[2] http://www.gluster.org/community /documentation/index.php/Bug_triage\n[3] https://forge.gluster.org/glusterfs -core/glusterfs/blobs/master/MAINTAINERS\n END:VEVENT END:VCALENDAR___ Gluster-users mailing list Gluster-users@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-users
