similar to: About the maintenance time

I currently use it in the replica configuration of 3.10.2. The brick process may not start when restarting the storage server. Also, when using gnfs, the I / O may hang up and become unusable. After checking the release notes of 3.11.0, the following ID seems to be applicable, so please reflect it if it can be reflected in 3.10 series. Also, for items with high urgency Since 3.11.0 has just been

On 06/16/2017 09:07 AM, te-yamauchi at usen.co.jp wrote: > I currently use it in the replica configuration of 3.10.2. > The brick process may not start when restarting the storage server. Also, when using gnfs, the I / O may hang up and become unusable. > After checking the release notes of 3.11.0, the following ID seems to be applicable, so please reflect it if it can be reflected in

On 06/15/2017 12:26 PM, te-yamauchi at usen.co.jp wrote: > What is the current stable version of glusterfs? 3.8.x and 3.10.x are long term stable releases. Newer features are in 3.11.x, which is a short term stable release branch. > Also, the current latest versions are 3.8.9, 3.10.3, and 3.11.0, respectively, but why the bug-fixed contents in 3.11.0 are not applied to 3.8 series and 3.10

It is componentized in Bug 1326219 and is not available by default. What package should I install to use gnfs? I can not find a package named glusterfs - gnfs. Thank you. -- Tetsuo

When using nfs-ganesha with GlusterFS, is it necessary to enable it with the following command? # gluster nfs-ganesha enable It is said that it is necessary to enable nfs-ganesha option when setting ganesha.enable on for volume. It is said that setting of ganesha-ha.conf is necessary, but is it necessary to set up HA to use nfs-ganesha? I would be pleased if you could tell me about HA setting

After 3.10 you'd need to use storhaug.... Which.... doesn't work (yet). You need to use 3.10 for now. On 07/06/2017 12:53 PM, Anthony Valentine wrote: > I'm running this on CentOS 7.3 > > [root at glustertest1 ~]# cat /etc/redhat-release > CentOS Linux release 7.3.1611 (Core) > > > Here are the software versions I have installed. > > [root at

Hello, I saw that parallel-readdir was an experimental feature in GlusterFS version 3.10.0, became stable in version 3.11.0, and is now recommended for small file workloads in the Red Hat Gluster Storage Server documentation[2]. I've successfully enabled this on one of my volumes but I notice the following in the client mount log: [2018-01-23 10:24:24.048055] W [MSGID: 101174]

Hi Hal, In that case what is the best way to query whether there is a loop carried dependence between B[j] and A[j] at i-loop level? We were operating under the assumption of 'conservatively correct' behavior of alias analysis in the function scope? Thanks, Pankaj From: Finkel, Hal J. <hfinkel at anl.gov> Sent: Tuesday, March 17, 2020 11:50 AM To: Hiroshi Yamauchi <yamauchi at

I had the same problem so i setup up hosts.allow to only allow access from certain ips i require This has the affect of killing the connection from any other ip befor gettign to any login prompt example below sshd : localhost : allow sshd : 192.168.2. : allow sshd : 82.41.115.213 :allow sshd : 216.123.248.219 : allow <-- public ip i wish to allow of course i have changed it sshd : all :

Adding devs who work on it On 23 Jan 2018 10:40 pm, "Alan Orth" <alan.orth at gmail.com> wrote: > Hello, > > I saw that parallel-readdir was an experimental feature in GlusterFS > version 3.10.0, became stable in version 3.11.0, and is now recommended for > small file workloads in the Red Hat Gluster Storage Server > documentation[2]. I've successfully

Glusterfs 3.10.3 has been tagged. Packages for the various distributions will be available in a few days, and with that a more formal release announcement will be made. - Tagged code: https://github.com/gluster/glusterfs/tree/v3.10.3 - Release notes: https://github.com/gluster/glusterfs/blob/release-3.10/doc/release-notes/3.10.3.md Thanks, Raghavendra Talur NOTE: Tracker bug for 3.10.3 will be

My understanding is that alias analysis returns results in the function scope, not in loop scope. Since both the phis access both global arrays, that should results in BasicAA conservatively returning MayAlias. I debugged this a little bit and narrowed it down to the section of the code in BasicAAResult::aliasPHI() which has this comment- // Analyse the PHIs' inputs under the assumption

@Zola, Eric, I really feel the communication and reasoning here is problematic. From my perspective, you removed stuff "we don't need", ignoring whether it is used, and then let people figure out how to deal with the result. What I most dislike about the process most is how questions and concerns are then ignored or played down. Thanks,   Johannes On 5/12/20 2:10 PM,

Just push :) On Tue, May 12, 2020, 8:46 AM Hiroshi Yamauchi <yamauchi at google.com> wrote: > I was also using "git llvm push" to commit, sort of out of habit. What's a > recommended, alternative way to push? > > On Mon, May 11, 2020 at 11:57 AM Johannes Doerfert via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I was actually using `git

On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > On Thu, May 10, 2018 at 12:49 PM Daniel Berlin <dberlin at dberlin.org> > wrote: > >> >> >> On Thu, May 10, 2018 at 12:05 PM, Hiroshi Yamauchi <yamauchi at google.com> >> wrote: >> >>> >>> >>> On Wed, May 9, 2018 at 8:24

For some reason this thread seems to be gone in a wrong direction. I'm sorry for that. The discussion on the RFC asked for a reason to keep the script, I think we heard reasons to do so (due to branches). Now, I was unable to determine if the `git llvm` scripts was removed "just as part of the bunch" or if we expect a problem with the script. If it is the former, are there

On Fri, May 11, 2018 at 7:20 PM Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/11/2018 08:40 PM, Daniel Berlin via llvm-dev wrote: > > > > On Fri, May 11, 2018 at 2:37 PM, Hiroshi Yamauchi <yamauchi at google.com> > wrote: > >> >> >> On Thu, May 10, 2018 at 12:49 PM Daniel Berlin <dberlin at dberlin.org> >> wrote: >>

----- Original Message ----- > From: "Pranith Kumar Karampuri" <pkarampu at redhat.com> > To: "Alan Orth" <alan.orth at gmail.com> > Cc: "gluster-users" <gluster-users at gluster.org> > Sent: Saturday, January 27, 2018 7:31:30 AM > Subject: Re: [Gluster-users] parallel-readdir is not recognized in GlusterFS 3.12.4 > > Adding

TBH, all I initially asked for, still ask for, is a reason why `git llvm` was being removed. Your email was the only one that hinted on a reason. (more below) On 5/12/20 4:00 PM, David Blaikie wrote: > On Tue, May 12, 2020 at 1:50 PM Johannes Doerfert via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> @Zola, Eric, >> >> >> I really feel the

On Thu, May 10, 2018 at 12:05 PM, Hiroshi Yamauchi <yamauchi at google.com> wrote: > > > On Wed, May 9, 2018 at 8:24 PM Daniel Berlin <dberlin at dberlin.org> wrote: > >> >> >> On Wed, May 9, 2018 at 10:39 AM, Hiroshi Yamauchi <yamauchi at google.com> >> wrote: >> >>> >>> >>> On Tue, May 8, 2018 at 11:15 AM