Re: [Gluster-devel] Not able to compile glusterfs

[Pranith Kumar Karampuri]

Thanks that helps.

On Mon, Mar 27, 2017 at 8:21 AM, Ravishankar N <ravishan...@redhat.com>
wrote:

> On 03/27/2017 06:30 AM, Pranith Kumar Karampuri wrote:
>
> hi,
> When I compile I get the following errors:
>
> EC dynamic support   : x64 sse avx
> Use memory pools : yes
> Nanosecond m/atimes  : yes
>
> file `cli1-xdr.tmp' already exists and may be overwritten
> file `changelog-xdr.tmp' already exists and may be overwritten
> file `glusterfs3-xdr.tmp' already exists and may be overwritten
> file `mount3udp.tmp' already exists and may be overwritten
> file `glusterd1-xdr.tmp' already exists and may be overwritten
> cp: cannot stat 'cli1-xdr.c': No such file or directory
> make[1]: *** [cli1-xdr.c] Error 1
> make[1]: *** Waiting for unfinished jobs
> file `rpc-common-xdr.tmp' already exists and may be overwritten
> file `portmap-xdr.tmp' already exists and may be overwritten
> file `nlm4-xdr.tmp' already exists and may be overwritten
> file `nsm-xdr.tmp' already exists and may be overwritten
> cp: file `glusterfs-fops.tmp' already exists and may be overwritten
> cannot stat 'mount3udp.c': No such file or directory
> make[1]: *** [mount3udp.c] Error 1
> cp: cannot stat 'changelog-xdr.c': No such file or directory
> make[1]: *** [changelog-xdr.c] Error 1
> cp: cp: cannot stat 'glusterfs3-xdr.c'cannot stat 'glusterd1-xdr.c': No
> such file or directory
> : No such file or directory
> cp: cannot stat 'rpc-common-xdr.c': No such file or directory
> make[1]: *** [glusterfs3-xdr.c] Error 1
> make[1]: *** [rpc-common-xdr.c] Error 1
> make[1]: *** [glusterd1-xdr.c] Error 1
> cp: cannot stat 'portmap-xdr.c': No such file or directory
> make[1]: *** [portmap-xdr.c] Error 1
> file `acl3-xdr.tmp' already exists and may be overwritten
> cp: cannot stat 'glusterfs-fops.c': No such file or directory
> cp: cannot stat 'nlm4-xdr.c': No such file or directory
> make[1]: *** [glusterfs-fops.c] Error 1
> make[1]: *** [nlm4-xdr.c] Error 1
> cp: cannot stat 'acl3-xdr.c': No such file or directory
> make[1]: *** [acl3-xdr.c] Error 1
> mv: cannot stat 'nsm-xdr.tmp': No such file or directory
> cp: cannot stat 'nsm-xdr.c': No such file or directory
> make[1]: *** [nsm-xdr.c] Error 1
> make: *** [install-recursive] Error 1
>
> Wondering if anyone else is facing the same problem. If there is a way to
> fix this please let me know.
>
> See the discussion on https://irclog.perlgeek.de/gluster-dev/2017-03-24#i_
> 14316697. It occurs when you run just 'make -j'. Kaleb has sent a fix
> https://review.gluster.org/#/c/16941/.
>
> -Ravi
>
>
> --
> Pranith
>
>
> ___
> Gluster-devel mailing 
> listGluster-devel@gluster.orghttp://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Maintainers 2.0 Proposal

[Pranith Kumar Karampuri]

On Sat, Mar 18, 2017 at 1:20 AM, Amar Tumballi  wrote:

> I don't want to take the discussions in another direction, but want
> clarity on few things:
>
> 1. Does maintainers means they are only reviewing/ merging patches?
> 2. Should maintainers be responsible for answering ML / IRC questions
> (well, they should focus more on documentation IMO).
> 3. Who's responsibility is it to keep the gluster.org webpage? I
> personally feel the responsibility should be well defined.
> 4. Can a component have more than 1 owner ? 1 maintainers etc?
>

More than 1 maintainer is the best case we should aim for. I see EC benefit
tremendously because of this. Work keeps moving because at least one of
Xavi/I are available for discussions.


>
> Some of these questions should be clearly answered in document IMO.
>
> Regards,
> Amar
>
>
> On Fri, Mar 17, 2017 at 11:55 PM, Amye Scavarda  wrote:
>
>> Posting in line, but it may be pretty hard to follow.
>> Apologies if I miss something.
>>
>> On Fri, Mar 17, 2017 at 11:06 AM, Niels de Vos  wrote:
>>
>>> On Wed, Mar 15, 2017 at 10:12:18PM -0400, Vijay Bellur wrote:
>>> > Hi All,
>>> >
>>> > We have been working on a proposal [1] to make the lifecycle
>>> management of
>>> > Gluster maintainers more structured. We intend to make the proposal
>>> > effective around 3.11 (May 2016).
>>> >
>>> > Please review the proposal and let us know your feedback. If you need
>>> > clarity on any existing aspect or feel the need for something
>>> additional in
>>> > the proposal, please feel free to let us know.
>>>
>>> I'll just include the proposal here and add inline comments. I'm not
>>> sure if this is the best way, or if you would like anyone edit the
>>> document directly...
>>>
>>> > Thanks!
>>> > Amye & Vijay
>>> >
>>> > [1]  https://hackmd.io/s/SkwiZd4qe
>>>
>>>
>>>
>>> > # Revised Maintainers for 3.11
>>> >
>>> > AI from Community Meeting, March 1:
>>> > amye to work on revised maintainers draft with vbellur to get out for
>>> > next maintainer's meeting. We'll approve it 'formally' there, see how
>>> it
>>> > works for 3.11.
>>>
>>> The next maintainers meeting happens when many maintainers are at VAULT.
>>> I would not expect a large attendance at that time. Also, Amye sent an
>>> email with a different target date?
>>>
>>
>> Feedback target date of 30 days, that's what I was indicating. This was
>> reviewed in the maintainers' meeting on March 8 and we're now expanding out
>> to the larger group.
>>
>>>
>>> > ## Goals:
>>> > * Refine how we declare component owners in Gluster
>>> > * Create a deeper sense of ownership throughout the open source project
>>> > * Welcome more contibutors at a project impacting level
>>>
>>> It would be good to make a distinction between the Gluster Community and
>>> the GlusterFS Project. "Gluster" refers in my understanding to all the
>>> projects of the Gluster Community. This document looks most aimed at the
>>> GlusterFS project, with some Gluster Community references.
>>
>>
>>
>> Is this distinction relevant? We're talking about how we define a
>> maintainer for contributing to the Gluster community overall. As I work
>> through this, I see your confusion. I don't think that we'd be able to make
>> this call for 'all related projects', but for committing back into Gluster
>> proper, yes.
>>
>>
>>>
>> > ## Definition of Owners + Peers
>>> > * Commit access to the project is not dependent on being a maintainer.
>>> A
>>> >   maintainer is a leadership role within the project to help drive the
>>> >   project forward.
>>>
>>> "the project", is that the glusterfs git repository, or any repository
>>> that we maintain? How would we see this for projects that contain
>>> Gluster modules like NFS-Ganesha and Samba? Or are those not considered
>>> as "our" components?
>>
>>
>> I think initially, we'd want to limit this to just the Gluster project.
>> Too much expansion and we'll have too much change too quickly.
>>
>>
>>>
>> > * Owner - Subject matter expert, help design large feature changes and
>>> >   decide overall goal of the component. Reviews patches, approves
>>> >   changes. Responsible for recruiting assisting peers. Owner of
>>> >   component. (Principle Software Engineer - unconnected to actual role
>>> >   in Red Hat organization)
>>>
>>> I would say a "subject matter expert" can give a +2 code-review in
>>> Gerrit, and the "owner" of the component would honour that opinion. I
>>> fail to see what "Principle Software Engineer" has to do with this if it
>>> is not connected to a role at Red Hat (hmm, I need to talk to my boss?).
>>>
>>>
>> I've gotten feedback that we should revisit the 'Principal' vs 'Senior'
>> framing - apologies. It was not the intention to make it Red Hat centric in
>> this way, but it was shorthand for responsibility areas. I'm happy to
>> revisit.
>>
>>
>>> > * Peer - assists with design, reviews. Growing into subject matter
>>> >   expert, but not required to 

Re: [Gluster-devel] Consistent time attributes (ctime, atime and mtime) across replica set and distribution set

[Pranith Kumar Karampuri]

On Wed, Mar 15, 2017 at 11:31 PM, Soumya Koduri  wrote:

> Hi Rafi,
>
> I haven't thoroughly gone through design. But have few comments/queries
> which I have posted inline for now .
>
> On 02/28/2017 01:11 PM, Mohammed Rafi K C wrote:
>
>> Thanks for the reply , Comments are inline
>>
>>
>>
>> On 02/28/2017 12:50 PM, Niels de Vos wrote:
>>
>>> On Tue, Feb 28, 2017 at 11:21:55AM +0530, Mohammed Rafi K C wrote:
>>>
 Hi All,


 We discussed the problem $subject in the mail thread [1]. Based on the
 comments and suggestions I will summarize the design (Made as points for
 simplicity.)


 1) As part of each fop, top layer will generate a time stamp and pass it
 to the down along with other param.

 1.1) This will bring a dependency for NTP synced clients along with
 servers

>>> What do you mean with "top layer"? Is this on the Gluster client, or
>>> does the time get inserted on the bricks?
>>>
>> It is the top layer (master xlator) in client graph like fuse, gfapi,
>> nfs . My mistake I should have mentioned . Sorry for that.
>>
>
> These clients shouldn't include internal client processes like rebalance,
> self-heal daemons right? IIUC from [1], we should avoid changing times
> during rebalance and self-heals.
>
> Also what about fops generated from the underlying layers -
> getxattr/setxattr which may modify these time attributes?
>
>
>>
>>
>>> I think we should not require a hard dependency on NTP, but have it
>>> strongly suggested. Having a synced time in a clustered environment is
>>> always helpful for reading and matching logs.
>>>
>> Agreed, but if we go with option 1 where we generate time from client,
>> then time will not be in sync if not done with NTP.
>>
>>
>>
>>
>>> 1.2) There can be a diff in time if the fop stuck in the xlator for
 various reason, for ex: because of locks.

>>> Or just slow networks? Blocking (mandatory?) locks should be handled
>>> correctly. The time a FOP is blocked can be long.
>>>
>> True, the questions can this be included in timestamp valie, because if
>> it generated from say fuse then when it reaches to the brick the time
>> may have moved ahead. what do you think about it ?
>>
>>
>>
>>> 2) On the server posix layer stores the value in the memory (inode ctx)
 and will sync the data periodically to the disk as an extended attr

>>> Will you use any timer thread for asynchronous update?
>
>
  2.1) of course sync call also will force it. And fop comes for an
 inode which is not linked, we do the sync immediately.

>>> Does it need to be in the posix layer?
>>>
>>
>> You mean storing the time attr ? then it need not be , protocol/server
>> is also another candidate but I feel posix is ahead in the race ;) .
>>
>
> I agree with Shyam and Niels that posix layer doesn't seem right. Since
> having this support comes with performance cost, how about a separate
> xlator (which shall be optional)?
>
>
>>
>>
>>> 3) Each time when inodes are created or initialized it read the data
 from disk and store it.


 4) Before setting to inode_ctx we compare the timestamp stored and the
 timestamp received, and only store if the stored value is lesser than
 the current value.

>>> If we choose not to set this attribute for self-heal/rebalance (as
> stated above) daemons, we would need special handling for the requests sent
> by them (i.e, to heal this time attribute as well on the destination
> file/dir).
>
>

 5) So in best case data will be stored and retrieved from the memory. We
 replace the values in iatt with the values in inode_ctx.


 6) File ops that changes the parent directory attr time need to be
 consistent across all the distributed directories across the subvolumes.
 (for eg: a create call will change ctime and mtime of parent dir)

  6.1) This has to handle separately because we only send the fop to
 the hashed subvolume.

  6.2) We can asynchronously send the timeupdate setattr fop to the
 other subvoumes and change the values for parent directory if the file
 fops is successful on hashed subvolume.

>>>
> The same needs to be handled even during DHT directory healing right?
>
>
  6.3) This will have a window where the times are inconsistent
 across dht subvolume (Please provide your suggestions)

>>> Isn't this the same problem for 'normal' AFR volumes? I guess self-heal
>>> needs to know how to pick the right value for the [cm]time xattr.
>>>
>>
>> Yes and need to heal. Both self heal and dht. But till then there can be
>> difference in values.
>>
>
> Is this design targetting to synchronize only ctime/mtime? If 'atime' is
> also considered , as the read/stat done by AFR shall modify atime only on
> the first subvol, even AFR xlator needs to take care of updating other
> subvols. Same goes with EC as well.
>

atime is updated on open which 

Re: [Gluster-devel] [Gluster-users] Glusterfs meta data space consumption issue

[Pranith Kumar Karampuri]

Is your backend filesystem ext4?

On Thu, Apr 13, 2017 at 6:29 AM, ABHISHEK PALIWAL 
wrote:

> No,we are not using sharding
> On Apr 12, 2017 7:29 PM, "Alessandro Briosi"  wrote:
>
>> Il 12/04/2017 14:16, ABHISHEK PALIWAL ha scritto:
>>
>> I have did more investigation and find out that brick dir size is
>> equivalent to gluster mount point but .glusterfs having too much difference
>>
>>
>> You are probably using sharding?
>>
>>
>> Buon lavoro.
>> *Alessandro Briosi*
>>
>> *METAL.it Nord S.r.l.*
>> Via Maioliche 57/C - 38068 Rovereto (TN)
>> Tel.+39.0464.430130 - Fax +39.0464.437393
>> www.metalit.com
>>
>>
>>
>
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Glusterfs meta data space consumption issue

[Pranith Kumar Karampuri]

Yes

On Thu, Apr 13, 2017 at 8:21 AM, ABHISHEK PALIWAL <abhishpali...@gmail.com>
wrote:

> Means the fs where this brick has been created?
> On Apr 13, 2017 8:19 AM, "Pranith Kumar Karampuri" <pkara...@redhat.com>
> wrote:
>
>> Is your backend filesystem ext4?
>>
>> On Thu, Apr 13, 2017 at 6:29 AM, ABHISHEK PALIWAL <
>> abhishpali...@gmail.com> wrote:
>>
>>> No,we are not using sharding
>>> On Apr 12, 2017 7:29 PM, "Alessandro Briosi" <a...@metalit.com> wrote:
>>>
>>>> Il 12/04/2017 14:16, ABHISHEK PALIWAL ha scritto:
>>>>
>>>> I have did more investigation and find out that brick dir size is
>>>> equivalent to gluster mount point but .glusterfs having too much difference
>>>>
>>>>
>>>> You are probably using sharding?
>>>>
>>>>
>>>> Buon lavoro.
>>>> *Alessandro Briosi*
>>>>
>>>> *METAL.it Nord S.r.l.*
>>>> Via Maioliche 57/C - 38068 Rovereto (TN)
>>>> Tel.+39.0464.430130 - Fax +39.0464.437393
>>>> www.metalit.com
>>>>
>>>>
>>>>
>>>
>>> ___
>>> Gluster-users mailing list
>>> gluster-us...@gluster.org
>>> http://lists.gluster.org/mailman/listinfo/gluster-users
>>>
>>
>>
>>
>> --
>> Pranith
>>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Glusterfs meta data space consumption issue

[Pranith Kumar Karampuri]

On Thu, Apr 13, 2017 at 12:19 PM, ABHISHEK PALIWAL <abhishpali...@gmail.com>
wrote:

> yes it is ext4. but what is the impact of this.
>

Did you have a lot of data before and you deleted all that data? ext4 if I
remember correctly doesn't decrease size of directory once it expands it.
So in ext4 inside a directory if you create lots and lots of files and
delete them all, the directory size would increase at the time of creation
but won't decrease after deletion. I don't have any system with ext4 at the
moment to test it now. This is something we faced 5-6 years back but not
sure if it is fixed in ext4 in the latest releases.


>
> On Thu, Apr 13, 2017 at 9:26 AM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>> Yes
>>
>> On Thu, Apr 13, 2017 at 8:21 AM, ABHISHEK PALIWAL <
>> abhishpali...@gmail.com> wrote:
>>
>>> Means the fs where this brick has been created?
>>> On Apr 13, 2017 8:19 AM, "Pranith Kumar Karampuri" <pkara...@redhat.com>
>>> wrote:
>>>
>>>> Is your backend filesystem ext4?
>>>>
>>>> On Thu, Apr 13, 2017 at 6:29 AM, ABHISHEK PALIWAL <
>>>> abhishpali...@gmail.com> wrote:
>>>>
>>>>> No,we are not using sharding
>>>>> On Apr 12, 2017 7:29 PM, "Alessandro Briosi" <a...@metalit.com> wrote:
>>>>>
>>>>>> Il 12/04/2017 14:16, ABHISHEK PALIWAL ha scritto:
>>>>>>
>>>>>> I have did more investigation and find out that brick dir size is
>>>>>> equivalent to gluster mount point but .glusterfs having too much 
>>>>>> difference
>>>>>>
>>>>>>
>>>>>> You are probably using sharding?
>>>>>>
>>>>>>
>>>>>> Buon lavoro.
>>>>>> *Alessandro Briosi*
>>>>>>
>>>>>> *METAL.it Nord S.r.l.*
>>>>>> Via Maioliche 57/C - 38068 Rovereto (TN)
>>>>>> Tel.+39.0464.430130 - Fax +39.0464.437393
>>>>>> www.metalit.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ___
>>>>> Gluster-users mailing list
>>>>> gluster-us...@gluster.org
>>>>> http://lists.gluster.org/mailman/listinfo/gluster-users
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Pranith
>>>>
>>>
>>
>>
>> --
>> Pranith
>>
>
>
>
> --
>
>
>
>
> Regards
> Abhishek Paliwal
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] High load on glusterfsd process

[Pranith Kumar Karampuri]

+Kotresh who seems to have worked on the bug you mentioned.

On Fri, Apr 21, 2017 at 12:21 PM, ABHISHEK PALIWAL 
wrote:

>
> If the patch provided in that case will resolve my bug as well then please
> provide the patch so that I will backport it on 3.7.6
>
> On Fri, Apr 21, 2017 at 11:30 AM, ABHISHEK PALIWAL <
> abhishpali...@gmail.com> wrote:
>
>> Hi Team,
>>
>> I have noticed that there are so many glusterfsd threads are running in
>> my system and we observed some of those thread consuming more cpu. I did
>> “strace” on two such threads (before the problem disappeared by itself) and
>> found that there is a continuous activity like below:
>>
>> lstat("/opt/lvmdir/c2/brick/.glusterfs/e7/7d/e77d12b3-92f8-4
>> dfe-9a7f-246e901cbdf1/002700/firewall_-J208482-425_20170126T113552+.log.gz",
>> {st_mode=S_IFREG|0670, st_size=1995, ...}) = 0
>> lgetxattr("/opt/lvmdir/c2/brick/.glusterfs/e7/7d/e77d12b3-
>> 92f8-4dfe-9a7f-246e901cbdf1/002700/firewall_-J208482-
>> 425_20170126T113552+.log.gz", "trusted.bit-rot.bad-file",
>> 0x3fff81f58550, 255) = -1 ENODATA (No data available)
>> lgetxattr("/opt/lvmdir/c2/brick/.glusterfs/e7/7d/e77d12b3-
>> 92f8-4dfe-9a7f-246e901cbdf1/002700/firewall_-J208482-
>> 425_20170126T113552+.log.gz", "trusted.bit-rot.signature",
>> 0x3fff81f58550, 255) = -1 ENODATA (No data available)
>> lstat("/opt/lvmdir/c2/brick/.glusterfs/e7/7d/e77d12b3-92f8-4
>> dfe-9a7f-246e901cbdf1/002700/tcli_-J208482-425_20170123T180550+.log.gz",
>> {st_mode=S_IFREG|0670, st_size=169, ...}) = 0
>> lgetxattr("/opt/lvmdir/c2/brick/.glusterfs/e7/7d/e77d12b3-
>> 92f8-4dfe-9a7f-246e901cbdf1/002700/tcli_-J208482-425_20170123T180550+.log.gz",
>> "trusted.bit-rot.bad-file", 0x3fff81f58550, 255) = -1 ENODATA (No data
>> available)
>> lgetxattr("/opt/lvmdir/c2/brick/.glusterfs/e7/7d/e77d12b3-
>> 92f8-4dfe-9a7f-246e901cbdf1/002700/tcli_-J208482-425_20170123T180550+.log.gz",
>> "trusted.bit-rot.signature", 0x3fff81f58550, 255) = -1 ENODATA (No data
>> available)
>>
>> I have found the below existing issue which is very similar to my
>> scenario.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1298258
>>
>> We are using the gluster-3.7.6 and it seems that the issue is fixed in
>> 3.8.4 version.
>>
>> Could you please let me know why it showing the number of above logs and
>> reason behind it as it is not explained in the above bug.
>>
>> Regards,
>> Abhishek
>>
>> --
>>
>>
>>
>>
>> Regards
>> Abhishek Paliwal
>>
>
>
>
> --
>
>
>
>
> Regards
> Abhishek Paliwal
>
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] fstest for fuse mount gluster

[Pranith Kumar Karampuri]

On Mon, Apr 24, 2017 at 11:28 AM, Raghavendra Gowdappa <rgowd...@redhat.com>
wrote:

> Its a known issue in DHT. Since DHT relies on some bits (S+T) in the stat
> for identifying that a file is being migrated by a rebalance process, it
> strips them off. But the problem is if the same bits are being used by
> application (as in this case). The fix (if we can come up with one) might
> require some time for validation as impact can be large. Possible solutions
> are:
>
> 1. Pranith pointed out that rebalance process always holds an inodelk
> during file migration. Probably we can leverage this information and decide
> whether to strip the flags or not.
> 2. There is also a linkto xattr stored on the data-file during migration.
> Instead of unconditionally striping Phase1(2) flags, lookup/stat codepaths
> can check for the presence of this xattr too and strip the flags only if it
> is present. Note that with this solution application won't see the (S+T)
> bits in stat during rebalance.
>

Innocent question. If we have a linkto-xattr and the lock, do we need
anything more to detect that migration is in progress? I am wondering if we
can remove the reliance on S+T bits. Worst case we will have to store the
info on the xattr.


>
> regards,
> Raghavendra.
>
> - Original Message -
> > From: "Pranith Kumar Karampuri" <pkara...@redhat.com>
> > To: "qingwei wei" <tcheng...@gmail.com>
> > Cc: "Gluster Devel" <gluster-devel@gluster.org>, "Raghavendra Gowdappa"
> <rgowd...@redhat.com>, "Nithya Balachandran"
> > <nbala...@redhat.com>
> > Sent: Monday, April 24, 2017 11:03:29 AM
> > Subject: Re: [Gluster-devel] fstest for fuse mount gluster
> >
> > This is a bug in dht it seems like. It is stripping PHASE1 flags
> > unconditionally.
> >
> > (gdb)
> > 1212DHT_STRIP_PHASE1_FLAGS (>stbuf);
> > (gdb) p local->stbuf.ia_prot
> > $18 = {
> >   suid = 1 '\001',
> >   sgid = 1 '\001', <---
> >   sticky = 1 '\001', <---
> > .
> > }
> > (gdb) n
> > 1213dht_set_fixed_dir_stat (>postparent);
> > (gdb) p local->stbuf.ia_prot
> > $19 = {
> >   suid = 1 '\001',
> >   sgid = 0 '\000', <---
> >   sticky = 0 '\000', <---
> > ...
> >
> > This is leading to -->4777
> >
> > Will update bug with same info
> >
> >
> > On Thu, Apr 20, 2017 at 8:58 PM, qingwei wei <tcheng...@gmail.com>
> wrote:
> >
> > > Hi,
> > >
> > > Posted this in gluster-user mailing list but got no response so far,
> so i
> > > post in gluster-devel.
> > >
> > > I found this test suite (https://github.com/Hnasar/pjdfstest) for me
> to
> > > test fuse mount gluster and there is some reported issue from the
> test. One
> > > of the error is as follow.
> > >
> > > When i chmod  to a file in fuse mounted gluster volume. the return
> > > stat value for the file is not  instead of 4777.
> > >
> > > root@ubuntu16d:/mnt/g310mp# touch test
> > > root@ubuntu16d:/mnt/g310mp# chmod  test
> > > root@ubuntu16d:/mnt/g310mp# stat test
> > >   File: 'test'
> > >   Size: 0   Blocks: 0  IO Block: 131072 regular
> empty
> > > file
> > > Device: 29h/41d Inode: 9618589997017543511  Links: 1
> > > Access: (4777/-rwsrwxrwx)  Uid: (0/root)   Gid: (0/
> root)
> > > Access: 2017-11-30 14:21:23.374871207 +0800
> > > Modify: 2017-11-30 14:21:16.974871000 +0800
> > > Change: 2017-11-30 14:21:23.374871207 +0800
> > >  Birth: -
> > >
> > > Performing this operation in normal ext4 system produce correct result.
> > >
> > > root@ubuntu16d:/mnt/g310mp# touch ~/testfile
> > > root@ubuntu16d:/mnt/g310mp# chmod  ~/testfile
> > > root@ubuntu16d:/mnt/g310mp# stat ~/testfile
> > >   File: '/home/ubuntu/testfile'
> > >   Size: 0   Blocks: 0  IO Block: 4096   regular
> empty
> > > file
> > > Device: fc00h/64512dInode: 662649  Links: 1
> > > Access: (/-rwsrwsrwt)  Uid: (0/root)   Gid: (0/
> root)
> > > Access: 2017-11-30 14:23:00.518867795 +0800
> > > Modify: 2017-11-30 14:23:00.518867795 +0800
> > > Change: 2017-11-30 14:23:08.742867507 +0800
> > >  Birth: -
> > >
> > > Besides , 3777 also an issue. The stat return is 0777.
> > >
> > > My OS is U

Re: [Gluster-devel] fstest for fuse mount gluster

[Pranith Kumar Karampuri]

This is a bug in dht it seems like. It is stripping PHASE1 flags
unconditionally.

(gdb)
1212DHT_STRIP_PHASE1_FLAGS (>stbuf);
(gdb) p local->stbuf.ia_prot
$18 = {
  suid = 1 '\001',
  sgid = 1 '\001', <---
  sticky = 1 '\001', <---
.
}
(gdb) n
1213dht_set_fixed_dir_stat (>postparent);
(gdb) p local->stbuf.ia_prot
$19 = {
  suid = 1 '\001',
  sgid = 0 '\000', <---
  sticky = 0 '\000', <---
...

This is leading to -->4777

Will update bug with same info


On Thu, Apr 20, 2017 at 8:58 PM, qingwei wei  wrote:

> Hi,
>
> Posted this in gluster-user mailing list but got no response so far, so i
> post in gluster-devel.
>
> I found this test suite (https://github.com/Hnasar/pjdfstest) for me to
> test fuse mount gluster and there is some reported issue from the test. One
> of the error is as follow.
>
> When i chmod  to a file in fuse mounted gluster volume. the return
> stat value for the file is not  instead of 4777.
>
> root@ubuntu16d:/mnt/g310mp# touch test
> root@ubuntu16d:/mnt/g310mp# chmod  test
> root@ubuntu16d:/mnt/g310mp# stat test
>   File: 'test'
>   Size: 0   Blocks: 0  IO Block: 131072 regular empty
> file
> Device: 29h/41d Inode: 9618589997017543511  Links: 1
> Access: (4777/-rwsrwxrwx)  Uid: (0/root)   Gid: (0/root)
> Access: 2017-11-30 14:21:23.374871207 +0800
> Modify: 2017-11-30 14:21:16.974871000 +0800
> Change: 2017-11-30 14:21:23.374871207 +0800
>  Birth: -
>
> Performing this operation in normal ext4 system produce correct result.
>
> root@ubuntu16d:/mnt/g310mp# touch ~/testfile
> root@ubuntu16d:/mnt/g310mp# chmod  ~/testfile
> root@ubuntu16d:/mnt/g310mp# stat ~/testfile
>   File: '/home/ubuntu/testfile'
>   Size: 0   Blocks: 0  IO Block: 4096   regular empty
> file
> Device: fc00h/64512dInode: 662649  Links: 1
> Access: (/-rwsrwsrwt)  Uid: (0/root)   Gid: (0/root)
> Access: 2017-11-30 14:23:00.518867795 +0800
> Modify: 2017-11-30 14:23:00.518867795 +0800
> Change: 2017-11-30 14:23:08.742867507 +0800
>  Birth: -
>
> Besides , 3777 also an issue. The stat return is 0777.
>
> My OS is Ubuntu 16.04 and my gluster version is 3.10.1 and the it is a
> simple volume with default parameter.
>
> root@ubuntu16d:/mnt/g310mp# gluster volume info
>
> Volume Name: g310
> Type: Distribute
> Volume ID: 114666c6-4884-436a-81a8-2deb3c0923ba
> Status: Started
> Snapshot Count: 0
> Number of Bricks: 1
> Transport-type: tcp
> Bricks:
> Brick1: 192.168.36.130:/mnt/g310brick
> Options Reconfigured:
> transport.address-family: inet
> nfs.disable: on
>
> for me, i seldom use those mode (3777 & ) but i cannot say for sure
> for others. So is this something i should be concerned about?
>
> Cw
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [master] [FAILED] [centos6] tests/bitrot/bug-1373520.t

[Pranith Kumar Karampuri]

Following patch fixed this already, I just rebased your change.

commit a2d4c928e93c95dfe2ceff450556f8494d67e654
Author: Krutika Dhananjay 
Date:   Wed Mar 1 12:48:10 2017 +0530

storage/posix: Set ret value correctly before exiting

Change-Id: I07c3a21c1c0625a517964693351356eead962571
BUG: 1427404
Signed-off-by: Krutika Dhananjay 
Reviewed-on: https://review.gluster.org/16792
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Raghavendra G 


On Tue, Feb 28, 2017 at 4:38 PM, Milind Changire 
wrote:

> 2 of 2 runs failed:
>
> https://build.gluster.org/job/centos6-regression/3451/consoleFull
>
> https://build.gluster.org/job/centos6-regression/3458/consoleFull
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] gfid and volume-id extended attributes lost

[Pranith Kumar Karampuri]

On Fri, Jul 7, 2017 at 9:15 PM, Pranith Kumar Karampuri <pkara...@redhat.com
> wrote:

> Did anything special happen on these two bricks? It can't happen in the
> I/O path:
> posix_removexattr() has:
>   0 if (!strcmp (GFID_XATTR_KEY, name))
> {
>
>
>   1 gf_msg (this->name, GF_LOG_WARNING, 0,
> P_MSG_XATTR_NOT_REMOVED,
>   2 "Remove xattr called on gfid for file %s",
> real_path);
>   3 op_ret = -1;
>
>   4 goto out;
>
>   5 }
>
>   6 if (!strcmp (GF_XATTR_VOL_ID_KEY, name))
> {
>   7 gf_msg (this->name, GF_LOG_WARNING, 0,
> P_MSG_XATTR_NOT_REMOVED,
>   8 "Remove xattr called on volume-id for file
> %s",
>   9 real_path);
>
>  10 op_ret = -1;
>
>  11 goto out;
>
>  12 }
>
> I just found that op_errno is not set correctly, but it can't happen in
> the I/O path, so self-heal/rebalance are off the hook.
>
> I also grepped for any removexattr of trusted.gfid from glusterd and
> didn't find any.
>
> So one thing that used to happen was that sometimes when machines reboot,
> the brick mounts wouldn't happen and this would lead to absence of both
> trusted.gfid and volume-id. So at the moment this is my wild guess.
>

Fix for this was to mount the bricks. But considering that you guys did
setting of the xattrs instead, I am guessing the other data was intact and
only these particular xattrs were missing? I wonder what new problem this
is.


>
>
> On Fri, Jul 7, 2017 at 8:39 PM, Ankireddypalle Reddy <are...@commvault.com
> > wrote:
>
>> Hi,
>>
>>We faced an issue in the production today. We had to stop the
>> volume and reboot all the servers in the cluster.  Once the servers
>> rebooted starting of the volume failed because the following extended
>> attributes were not present on all the bricks on 2 servers.
>>
>> 1)  trusted.gfid
>>
>> 2)  trusted.glusterfs.volume-id
>>
>>
>>
>> We had to manually set these extended attributes to start the volume.
>> Are there any such known issues.
>>
>>
>>
>> Thanks and Regards,
>>
>> Ram
>> ***Legal Disclaimer***
>> "This communication may contain confidential and privileged material for
>> the
>> sole use of the intended recipient. Any unauthorized review, use or
>> distribution
>> by others is strictly prohibited. If you have received the message by
>> mistake,
>> please advise the sender by reply email and delete the message. Thank
>> you."
>> **
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Pranith
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] gfid and volume-id extended attributes lost

[Pranith Kumar Karampuri]

On Fri, Jul 7, 2017 at 9:25 PM, Ankireddypalle Reddy <are...@commvault.com>
wrote:

> 3.7.19
>

These are the only callers for removexattr and only _posix_remove_xattr has
the potential to do removexattr as posix_removexattr already makes sure
that it is not gfid/volume-id. And surprise surprise _posix_remove_xattr
happens only from healing code of afr/ec. And this can only happen if the
source brick doesn't have gfid, which doesn't seem to match with the
situation you explained.

   #   line  filename / context / line
   1   1234  xlators/mgmt/glusterd/src/glusterd-quota.c
<>
 ret = sys_lremovexattr (abspath, QUOTA_LIMIT_KEY);
   2   1243  xlators/mgmt/glusterd/src/glusterd-quota.c
<>
 ret = sys_lremovexattr (abspath, QUOTA_LIMIT_OBJECTS_KEY);
   3   6102  xlators/mgmt/glusterd/src/glusterd-utils.c
<>
 sys_lremovexattr (path, "trusted.glusterfs.test");
   4 80  xlators/storage/posix/src/posix-handle.h <>
 op_ret = sys_lremovexattr (path, key); \
   5   5026  xlators/storage/posix/src/posix.c <<_posix_remove_xattr>>
 op_ret = sys_lremovexattr (filler->real_path, key);
   6   5101  xlators/storage/posix/src/posix.c <>
 op_ret = sys_lremovexattr (real_path, name);
   7   6811  xlators/storage/posix/src/posix.c <>
 sys_lremovexattr (dir_data->data, "trusted.glusterfs.test");

So there are only two possibilities:
1) Source directory in ec/afr doesn't have gfid
2) Something else removed these xattrs.

What is your volume info? May be that will give more clues.

 PS: sys_fremovexattr is called only from posix_fremovexattr(), so that
doesn't seem to be the culprit as it also have checks to guard against
gfid/volume-id removal.


>
> Thanks and Regards,
>
> Ram
>
> *From:* Pranith Kumar Karampuri [mailto:pkara...@redhat.com]
> *Sent:* Friday, July 07, 2017 11:54 AM
>
> *To:* Ankireddypalle Reddy
> *Cc:* Gluster Devel (gluster-devel@gluster.org); gluster-us...@gluster.org
> *Subject:* Re: [Gluster-devel] gfid and volume-id extended attributes lost
>
>
>
>
>
>
>
> On Fri, Jul 7, 2017 at 9:20 PM, Ankireddypalle Reddy <are...@commvault.com>
> wrote:
>
> Pranith,
>
>  Thanks for looking in to the issue. The bricks were
> mounted after the reboot. One more thing that I noticed was when the
> attributes were manually set when glusterd was up then on starting the
> volume the attributes were again lost. Had to stop glusterd set attributes
> and then start glusterd. After that the volume start succeeded.
>
>
>
> Which version is this?
>
>
>
>
>
> Thanks and Regards,
>
> Ram
>
>
>
> *From:* Pranith Kumar Karampuri [mailto:pkara...@redhat.com]
> *Sent:* Friday, July 07, 2017 11:46 AM
> *To:* Ankireddypalle Reddy
> *Cc:* Gluster Devel (gluster-devel@gluster.org); gluster-us...@gluster.org
> *Subject:* Re: [Gluster-devel] gfid and volume-id extended attributes lost
>
>
>
> Did anything special happen on these two bricks? It can't happen in the
> I/O path:
> posix_removexattr() has:
>   0 if (!strcmp (GFID_XATTR_KEY, name))
> {
>
>
>   1 gf_msg (this->name, GF_LOG_WARNING, 0,
> P_MSG_XATTR_NOT_REMOVED,
>   2 "Remove xattr called on gfid for file %s",
> real_path);
>   3 op_ret = -1;
>
>   4 goto out;
>
>   5 }
>
>   6 if (!strcmp (GF_XATTR_VOL_ID_KEY, name))
> {
>   7 gf_msg (this->name, GF_LOG_WARNING, 0,
> P_MSG_XATTR_NOT_REMOVED,
>   8 "Remove xattr called on volume-id for file
> %s",
>   9 real_path);
>
>  10 op_ret = -1;
>
>  11 goto out;
>
>  12 }
>
> I just found that op_errno is not set correctly, but it can't happen in
> the I/O path, so self-heal/rebalance are off the hook.
>
> I also grepped for any removexattr of trusted.gfid from glusterd and
> didn't find any.
>
> So one thing that used to happen was that sometimes when machines reboot,
> the brick mounts wouldn't happen and this would lead to absence of both
> trusted.gfid and volume-id. So at the moment this is my wild guess.
>
>
>
>
>
> On Fri, Jul 7, 2017 at 8:39 PM, Ankireddypalle Reddy <are...@commvault.com>
> wrote:
>
> Hi,
>
>We faced an issue in the production today. We had to stop the
> volume and reboot all the servers in the cluster.  Once the servers
> rebooted starting of the volume failed because the following extended
> attributes were not present on all the bricks on 2 servers.
>
> 1)  tr

Re: [Gluster-devel] gfid and volume-id extended attributes lost

[Pranith Kumar Karampuri]

On Fri, Jul 7, 2017 at 9:20 PM, Ankireddypalle Reddy <are...@commvault.com>
wrote:

> Pranith,
>
>  Thanks for looking in to the issue. The bricks were
> mounted after the reboot. One more thing that I noticed was when the
> attributes were manually set when glusterd was up then on starting the
> volume the attributes were again lost. Had to stop glusterd set attributes
> and then start glusterd. After that the volume start succeeded.
>

Which version is this?


>
>
> Thanks and Regards,
>
> Ram
>
>
>
> *From:* Pranith Kumar Karampuri [mailto:pkara...@redhat.com]
> *Sent:* Friday, July 07, 2017 11:46 AM
> *To:* Ankireddypalle Reddy
> *Cc:* Gluster Devel (gluster-devel@gluster.org); gluster-us...@gluster.org
> *Subject:* Re: [Gluster-devel] gfid and volume-id extended attributes lost
>
>
>
> Did anything special happen on these two bricks? It can't happen in the
> I/O path:
> posix_removexattr() has:
>   0 if (!strcmp (GFID_XATTR_KEY, name))
> {
>
>
>   1 gf_msg (this->name, GF_LOG_WARNING, 0,
> P_MSG_XATTR_NOT_REMOVED,
>   2 "Remove xattr called on gfid for file %s",
> real_path);
>   3 op_ret = -1;
>
>   4 goto out;
>
>   5 }
>
>   6 if (!strcmp (GF_XATTR_VOL_ID_KEY, name))
> {
>   7 gf_msg (this->name, GF_LOG_WARNING, 0,
> P_MSG_XATTR_NOT_REMOVED,
>   8 "Remove xattr called on volume-id for file
> %s",
>   9 real_path);
>
>  10 op_ret = -1;
>
>  11 goto out;
>
>  12 }
>
> I just found that op_errno is not set correctly, but it can't happen in
> the I/O path, so self-heal/rebalance are off the hook.
>
> I also grepped for any removexattr of trusted.gfid from glusterd and
> didn't find any.
>
> So one thing that used to happen was that sometimes when machines reboot,
> the brick mounts wouldn't happen and this would lead to absence of both
> trusted.gfid and volume-id. So at the moment this is my wild guess.
>
>
>
>
>
> On Fri, Jul 7, 2017 at 8:39 PM, Ankireddypalle Reddy <are...@commvault.com>
> wrote:
>
> Hi,
>
>We faced an issue in the production today. We had to stop the
> volume and reboot all the servers in the cluster.  Once the servers
> rebooted starting of the volume failed because the following extended
> attributes were not present on all the bricks on 2 servers.
>
> 1)  trusted.gfid
>
> 2)  trusted.glusterfs.volume-id
>
>
>
> We had to manually set these extended attributes to start the volume.  Are
> there any such known issues.
>
>
>
> Thanks and Regards,
>
> Ram
>
> ***Legal Disclaimer***
>
> "This communication may contain confidential and privileged material for
> the
>
> sole use of the intended recipient. Any unauthorized review, use or
> distribution
>
> by others is strictly prohibited. If you have received the message by
> mistake,
>
> please advise the sender by reply email and delete the message. Thank you."
>
> **
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
>
>
> --
>
> Pranith
> ***Legal Disclaimer***
> "This communication may contain confidential and privileged material for
> the
> sole use of the intended recipient. Any unauthorized review, use or
> distribution
> by others is strictly prohibited. If you have received the message by
> mistake,
> please advise the sender by reply email and delete the message. Thank you."
> **
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] gfid and volume-id extended attributes lost

[Pranith Kumar Karampuri]

Did anything special happen on these two bricks? It can't happen in the I/O
path:
posix_removexattr() has:
  0 if (!strcmp (GFID_XATTR_KEY, name))
{

  1 gf_msg (this->name, GF_LOG_WARNING, 0,
P_MSG_XATTR_NOT_REMOVED,
  2 "Remove xattr called on gfid for file %s",
real_path);
  3 op_ret =
-1;
  4 goto
out;
  5
}
  6 if (!strcmp (GF_XATTR_VOL_ID_KEY, name))
{
  7 gf_msg (this->name, GF_LOG_WARNING, 0,
P_MSG_XATTR_NOT_REMOVED,
  8 "Remove xattr called on volume-id for file
%s",
  9
real_path);
 10 op_ret =
-1;
 11 goto
out;
 12 }

I just found that op_errno is not set correctly, but it can't happen in the
I/O path, so self-heal/rebalance are off the hook.

I also grepped for any removexattr of trusted.gfid from glusterd and didn't
find any.

So one thing that used to happen was that sometimes when machines reboot,
the brick mounts wouldn't happen and this would lead to absence of both
trusted.gfid and volume-id. So at the moment this is my wild guess.


On Fri, Jul 7, 2017 at 8:39 PM, Ankireddypalle Reddy 
wrote:

> Hi,
>
>We faced an issue in the production today. We had to stop the
> volume and reboot all the servers in the cluster.  Once the servers
> rebooted starting of the volume failed because the following extended
> attributes were not present on all the bricks on 2 servers.
>
> 1)  trusted.gfid
>
> 2)  trusted.glusterfs.volume-id
>
>
>
> We had to manually set these extended attributes to start the volume.  Are
> there any such known issues.
>
>
>
> Thanks and Regards,
>
> Ram
> ***Legal Disclaimer***
> "This communication may contain confidential and privileged material for
> the
> sole use of the intended recipient. Any unauthorized review, use or
> distribution
> by others is strictly prohibited. If you have received the message by
> mistake,
> please advise the sender by reply email and delete the message. Thank you."
> **
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] crash in tests/bugs/core/bug-1432542-mpx-restart-crash.t

[Pranith Kumar Karampuri]

I just observed that
https://build.gluster.org/job/centos6-regression/5433/consoleFull failed
because of this .t failure.

-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Build failed in Jenkins: regression-test-with-multiplex #162

[Pranith Kumar Karampuri]

Ah! sorry, I need to keep this in mind next time when I review.

On Mon, Jul 17, 2017 at 6:30 PM, Atin Mukherjee  wrote:

> kill $pid0
>
> kill $pid1
>
> EXPECT_WITHIN $CHILD_UP_TIMEOUT "4" ec_child_up_count $V0 0
>
> *21:03:33* not ok 17 Got "0" instead of "4", LINENUM:40*21:03:33* FAILED 
> COMMAND: 4 ec_child_up_count patchy 0
>
> The failure is quite obvious with brick multiplexing as all the brick 
> instances go down with kill signal. We need to use kill_brick utility here to 
> ensure
> the test is compatible with brick multiplexing.
>
>
>
> On Sun, Jul 16, 2017 at 1:22 PM, Atin Mukherjee 
> wrote:
>
>> EC dev - tests/basic/ec/ec-1468261.t is failing frequently now with
>> brick multiplex enabled. Please have a look.
>>
>> -- Forwarded message -
>> From: 
>> Date: Sun, 16 Jul 2017 at 06:32
>> Subject: [Gluster-Maintainers] Build failed in Jenkins:
>> regression-test-with-multiplex #162
>> To: , , ,
>> 
>>
>>
>> See > x/162/display/redirect>
>>
>> --
>> [...truncated 742.19 KB...]
>> ./tests/bugs/glusterd/bug-1070734.t  -  13 second
>> ./tests/bugs/distribute/bug-961615.t  -  13 second
>> ./tests/bugs/bitrot/1207029-bitrot-daemon-should-start-on-valid-node.t
>> -  13 second
>> ./tests/bitrot/bug-1207627-bitrot-scrub-status.t  -  13 second
>> ./tests/basic/rpc-coverage.t  -  13 second
>> ./tests/basic/quota_aux_mount.t  -  13 second
>> ./tests/basic/inode-quota-enforcing.t  -  13 second
>> ./tests/basic/glusterd/arbiter-volume-probe.t  -  13 second
>> ./tests/performance/open-behind.t  -  12 second
>> ./tests/bugs/replicate/bug-986905.t  -  12 second
>> ./tests/bugs/replicate/bug-1325792.t  -  12 second
>> ./tests/bugs/quota/bug-1250582-volume-reset-should-not-
>> remove-quota-quota-deem-statfs.t  -  12 second
>> ./tests/bugs/nfs/bug-904065.t  -  12 second
>> ./tests/bugs/glusterfs/bug-902610.t  -  12 second
>> ./tests/bugs/glusterfs/bug-872923.t  -  12 second
>> ./tests/bugs/glusterd/bug-955588.t  -  12 second
>> ./tests/bugs/glusterd/bug-949930.t  -  12 second
>> ./tests/bugs/glusterd/bug-1121584-brick-existing-validation-
>> for-remove-brick-status-stop.t  -  12 second
>> ./tests/bugs/fuse/bug-985074.t  -  12 second
>> ./tests/bugs/distribute/bug-1247563.t  -  12 second
>> ./tests/bugs/distribute/bug-1088231.t  -  12 second
>> ./tests/bugs/cli/bug-1030580.t  -  12 second
>> ./tests/basic/volume-status.t  -  12 second
>> ./tests/basic/stats-dump.t  -  12 second
>> ./tests/basic/pump.t  -  12 second
>> ./tests/basic/ec/ec-root-heal.t  -  12 second
>> ./tests/bugs/replicate/bug-1448804-check-quorum-type-values.t  -  11
>> second
>> ./tests/bugs/replicate/bug-1250170-fsync.t  -  11 second
>> ./tests/bugs/replicate/bug-1132102.t  -  11 second
>> ./tests/bugs/posix/bug-1360679.t  -  11 second
>> ./tests/bugs/posix/bug-1122028.t  -  11 second
>> ./tests/bugs/nfs/bug-1157223-symlink-mounting.t  -  11 second
>> ./tests/bugs/md-cache/bug-1211863.t  -  11 second
>> ./tests/bugs/glusterd/bug-948729/bug-948729-mode-script.t  -  11 second
>> ./tests/bugs/glusterd/bug-948729/bug-948729-force.t  -  11 second
>> ./tests/bugs/glusterd/bug-889630.t  -  11 second
>> ./tests/bugs/glusterd/bug-1242875-do-not-pass-volinfo-quota.t  -  11
>> second
>> ./tests/bugs/glusterd/bug-1046308.t  -  11 second
>> ./tests/bugs/ec/bug-1179050.t  -  11 second
>> ./tests/bugs/distribute/bug-1122443.t  -  11 second
>> ./tests/bugs/distribute/bug-1086228.t  -  11 second
>> ./tests/bugs/cli/bug-1087487.t  -  11 second
>> ./tests/bugs/cli/bug-1022905.t  -  11 second
>> ./tests/bugs/bitrot/1209818-vol-info-show-scrub-process-properly.t  -
>> 11 second
>> ./tests/basic/quota-nfs.t  -  11 second
>> ./tests/basic/md-cache/bug-1317785.t  -  11 second
>> ./tests/basic/gfapi/upcall-cache-invalidate.t  -  11 second
>> ./tests/basic/fop-sampling.t  -  11 second
>> ./tests/basic/ec/ec-read-policy.t  -  11 second
>> ./tests/features/ssl-authz.t  -  10 second
>> ./tests/bugs/upcall/bug-1458127.t  -  10 second
>> ./tests/bugs/upcall/bug-1227204.t  -  10 second
>> ./tests/bugs/transport/bug-873367.t  -  10 second
>> ./tests/bugs/tier/bug-1205545-CTR-and-trash-integration.t  -  10 second
>> ./tests/bugs/snapshot/bug-1260848.t  -  10 second
>> ./tests/bugs/quota/bug-1287996.t  -  10 second
>> ./tests/bugs/quota/bug-1243798.t  -  10 second
>> ./tests/bugs/nfs/bug-1143880-fix-gNFSd-auth-crash.t  -  10 second
>> ./tests/bugs/io-cache/bug-read-hang.t  -  10 second
>> ./tests/bugs/glusterd/bug-948729/bug-948729.t  -  10 second
>> ./tests/bugs/glusterd/bug-1179175-uss-option-validation.t  -  10 second
>> ./tests/bugs/glusterd/bug-1091935-brick-order-check-from-cli-to-glusterd.t
>> -  10 second
>> ./tests/bugs/glusterd/bug-1022055.t  -  10 second
>> ./tests/bugs/ec/bug-1227869.t  -  10 second
>> 

Re: [Gluster-devel] GlusterFS v3.12 - Nearing deadline for branch out

[Pranith Kumar Karampuri]

hi,
   Status of the following features targeted for 3.12:
1) Need a way to resolve split-brain (#135) : Mostly will be merged in a
day.
2) Halo Hybrid mode (#217): Unfortunately didn't get time to follow up on
this, so will not make it to the release.
3) Implement heal throttling (#255): Won't be making it to 3.12
4) Delay generator xlator (#257): I can definitely get this in by End of
next week, otherwise we can do this for next release.
5) Parallel writes in EC (#251): This seems like a stretch for this weekend
but definitely completable by end of next week. I am hopeful Xavi will have
some cycles to complete the final reviews. Otherwise we may have to push
this out.
6) Discard support for EC (#254): Doable for this weekend IMO, also depends
on what Xavi thinks...
7) Last stripe caching (#256): We are targetting this instead of heal
throttling (#255). This is not added to 3.12 tracker. I can add this if we
can wait till next week. This also depends on Xavi's schedule.

Also added Xavi for his inputs.


On Wed, Jul 5, 2017 at 9:07 PM, Shyam  wrote:

> Further to this,
>
> 1) I cleared up the projects lane [1] and also issues marked for 3.12 [2]
>   - I did this optimistically, moving everything to 3.12 (both from a
> projects and a milestones perspective), so if something is not making it,
> drop a note, and we can clear up the tags accordingly.
>
> 2) Reviews posted and open against the issues in [1] can be viewed here [3]
>
>   - Request maintainers and contributors to take a look at these and
> accelerate the reviews, to meet the feature cut-off deadline
>
>   - Request feature owners to ensure that their patches are listed in the
> link [3]
>
> 3) Finally, we need a status of open issues to understand how we can help.
> Requesting all feature owners to post the same (as Amar has requested).
>
> Thanks,
> Shyam
>
> [1] Project lane: https://github.com/gluster/glusterfs/projects/1
> [2] Issues with 3.12 milestone: https://github.com/gluster/glu
> sterfs/milestone/4
> [3] Reviews needing attetion: https://review.gluster.org/#/q
> /starredby:srangana%2540redhat.com
>
> "Releases are made better together"
>
>
> On 07/05/2017 03:18 AM, Amar Tumballi wrote:
>
>> All,
>>
>> We are around 10 working days remaining for branching out for 3.12
>> release, after which, we will have just 15 more days open for 'critical'
>> features to get in, for which there should be more detailed proposals.
>>
>> If you have few things planned out, but haven't taken it to completion
>> yet, OR you have sent some patches, but not yet reviewed, start whining
>> now, and get these in.
>>
>> Thanks,
>> Amar
>>
>> --
>> Amar Tumballi (amarts)
>>
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] gfid and volume-id extended attributes lost

[Pranith Kumar Karampuri]

Ram,
   As per the code, self-heal was the only candidate which *can* do it.
Could you check logs of self-heal daemon and the mount to check if there
are any metadata heals on root?


+Sanoj

Sanoj,
   Is there any systemtap script we can use to detect which process is
removing these xattrs?

On Sat, Jul 8, 2017 at 2:58 AM, Ankireddypalle Reddy <are...@commvault.com>
wrote:

> We lost the attributes on all the bricks on servers glusterfs2 and
> glusterfs3 again.
>
>
>
> [root@glusterfs2 Log_Files]# gluster volume info
>
>
>
> Volume Name: StoragePool
>
> Type: Distributed-Disperse
>
> Volume ID: 149e976f-4e21-451c-bf0f-f5691208531f
>
> Status: Started
>
> Number of Bricks: 20 x (2 + 1) = 60
>
> Transport-type: tcp
>
> Bricks:
>
> Brick1: glusterfs1sds:/ws/disk1/ws_brick
>
> Brick2: glusterfs2sds:/ws/disk1/ws_brick
>
> Brick3: glusterfs3sds:/ws/disk1/ws_brick
>
> Brick4: glusterfs1sds:/ws/disk2/ws_brick
>
> Brick5: glusterfs2sds:/ws/disk2/ws_brick
>
> Brick6: glusterfs3sds:/ws/disk2/ws_brick
>
> Brick7: glusterfs1sds:/ws/disk3/ws_brick
>
> Brick8: glusterfs2sds:/ws/disk3/ws_brick
>
> Brick9: glusterfs3sds:/ws/disk3/ws_brick
>
> Brick10: glusterfs1sds:/ws/disk4/ws_brick
>
> Brick11: glusterfs2sds:/ws/disk4/ws_brick
>
> Brick12: glusterfs3sds:/ws/disk4/ws_brick
>
> Brick13: glusterfs1sds:/ws/disk5/ws_brick
>
> Brick14: glusterfs2sds:/ws/disk5/ws_brick
>
> Brick15: glusterfs3sds:/ws/disk5/ws_brick
>
> Brick16: glusterfs1sds:/ws/disk6/ws_brick
>
> Brick17: glusterfs2sds:/ws/disk6/ws_brick
>
> Brick18: glusterfs3sds:/ws/disk6/ws_brick
>
> Brick19: glusterfs1sds:/ws/disk7/ws_brick
>
> Brick20: glusterfs2sds:/ws/disk7/ws_brick
>
> Brick21: glusterfs3sds:/ws/disk7/ws_brick
>
> Brick22: glusterfs1sds:/ws/disk8/ws_brick
>
> Brick23: glusterfs2sds:/ws/disk8/ws_brick
>
> Brick24: glusterfs3sds:/ws/disk8/ws_brick
>
> Brick25: glusterfs4sds.commvault.com:/ws/disk1/ws_brick
>
> Brick26: glusterfs5sds.commvault.com:/ws/disk1/ws_brick
>
> Brick27: glusterfs6sds.commvault.com:/ws/disk1/ws_brick
>
> Brick28: glusterfs4sds.commvault.com:/ws/disk10/ws_brick
>
> Brick29: glusterfs5sds.commvault.com:/ws/disk10/ws_brick
>
> Brick30: glusterfs6sds.commvault.com:/ws/disk10/ws_brick
>
> Brick31: glusterfs4sds.commvault.com:/ws/disk11/ws_brick
>
> Brick32: glusterfs5sds.commvault.com:/ws/disk11/ws_brick
>
> Brick33: glusterfs6sds.commvault.com:/ws/disk11/ws_brick
>
> Brick34: glusterfs4sds.commvault.com:/ws/disk12/ws_brick
>
> Brick35: glusterfs5sds.commvault.com:/ws/disk12/ws_brick
>
> Brick36: glusterfs6sds.commvault.com:/ws/disk12/ws_brick
>
> Brick37: glusterfs4sds.commvault.com:/ws/disk2/ws_brick
>
> Brick38: glusterfs5sds.commvault.com:/ws/disk2/ws_brick
>
> Brick39: glusterfs6sds.commvault.com:/ws/disk2/ws_brick
>
> Brick40: glusterfs4sds.commvault.com:/ws/disk3/ws_brick
>
> Brick41: glusterfs5sds.commvault.com:/ws/disk3/ws_brick
>
> Brick42: glusterfs6sds.commvault.com:/ws/disk3/ws_brick
>
> Brick43: glusterfs4sds.commvault.com:/ws/disk4/ws_brick
>
> Brick44: glusterfs5sds.commvault.com:/ws/disk4/ws_brick
>
> Brick45: glusterfs6sds.commvault.com:/ws/disk4/ws_brick
>
> Brick46: glusterfs4sds.commvault.com:/ws/disk5/ws_brick
>
> Brick47: glusterfs5sds.commvault.com:/ws/disk5/ws_brick
>
> Brick48: glusterfs6sds.commvault.com:/ws/disk5/ws_brick
>
> Brick49: glusterfs4sds.commvault.com:/ws/disk6/ws_brick
>
> Brick50: glusterfs5sds.commvault.com:/ws/disk6/ws_brick
>
> Brick51: glusterfs6sds.commvault.com:/ws/disk6/ws_brick
>
> Brick52: glusterfs4sds.commvault.com:/ws/disk7/ws_brick
>
> Brick53: glusterfs5sds.commvault.com:/ws/disk7/ws_brick
>
> Brick54: glusterfs6sds.commvault.com:/ws/disk7/ws_brick
>
> Brick55: glusterfs4sds.commvault.com:/ws/disk8/ws_brick
>
> Brick56: glusterfs5sds.commvault.com:/ws/disk8/ws_brick
>
> Brick57: glusterfs6sds.commvault.com:/ws/disk8/ws_brick
>
> Brick58: glusterfs4sds.commvault.com:/ws/disk9/ws_brick
>
> Brick59: glusterfs5sds.commvault.com:/ws/disk9/ws_brick
>
> Brick60: glusterfs6sds.commvault.com:/ws/disk9/ws_brick
>
> Options Reconfigured:
>
> performance.readdir-ahead: on
>
> diagnostics.client-log-level: INFO
>
> auth.allow: glusterfs1sds,glusterfs2sds,glusterfs3sds,glusterfs4sds.
> commvault.com,glusterfs5sds.commvault.com,glusterfs6sds.commvault.com
>
>
>
> Thanks and Regards,
>
> Ram
>
> *From:* Pranith Kumar Karampuri [mailto:pkara...@redhat.com]
> *Sent:* Friday, July 07, 2017 12:15 PM
>
> *To:* Ankireddypalle Reddy
> *Cc:* Gluster Devel (gluster-devel@gluster.org); gluster-us...@gluster

Re: [Gluster-devel] create restrictions xlator

[Pranith Kumar Karampuri]

hey,
  I went through the patch. I see that statfs is always wound for
create fop. So number of network operations increase and performance will
be less even in normal case. I think similar functionality is in DHT, may
be you should take a look at that?

Check dht_get_du_info() which is used by dht_mknod(). It keeps refreshing
this info every X seconds. I will let DHT guys comment a bit more about
this. One more thing to check is if we can have just one implementation
that satisfied everyone's requirements. i.e. move out this functionality
from DHT to this xlator or, move the functionality of this xlator into DHT.


On Thu, Jul 13, 2017 at 8:18 AM, Taehwa Lee  wrote:

> Hi all,
>
> I’ve been developing a xlator that create is rejected when used capacity
> of a volume higher than threshold.
>
>
> the reason why I’m doing is that I got problems when LV is used fully.
>
> this patch is in the middle of develop.
>
> just I want to know whether my approach is pretty correct to satisfy my
> requirement.
>
> so, when you guys have a little spare time, please review my patch and
> tell me WHATEVER you’re thinking.
>
>
> and If you guys think that it is useful for glusterfs, I’m gonna do
> process to merge into glusterfs.
>
>
> thanks in advance
>
>
>
>
>
> -
> Taehwa Lee
> Gluesys Co.,Ltd.
> alghost@gmail.com
> +82-10-3420-6114, +82-70-8785-6591
> -
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] gfid and volume-id extended attributes lost

[Pranith Kumar Karampuri]

Ram,
  I sent https://review.gluster.org/17765 to fix the possibility in
bulk removexattr. But I am not sure if this is indeed the reason for this
issue.

On Mon, Jul 10, 2017 at 6:30 PM, Ankireddypalle Reddy <are...@commvault.com>
wrote:

> Thanks for the swift turn around. Will try this out and let you know.
>
>
>
> Thanks and Regards,
>
> Ram
>
> *From:* Pranith Kumar Karampuri [mailto:pkara...@redhat.com]
> *Sent:* Monday, July 10, 2017 8:31 AM
> *To:* Sanoj Unnikrishnan
> *Cc:* Ankireddypalle Reddy; Gluster Devel (gluster-devel@gluster.org);
> gluster-us...@gluster.org
>
> *Subject:* Re: [Gluster-devel] gfid and volume-id extended attributes lost
>
>
>
> Ram,
>
>   If you see it again, you can use this. I am going to send out a
> patch for the code path which can lead to removal of gfid/volume-id
> tomorrow.
>
>
>
> On Mon, Jul 10, 2017 at 5:19 PM, Sanoj Unnikrishnan <sunni...@redhat.com>
> wrote:
>
> Please use the systemtap script(https://paste.fedoraproject.org/paste/
> EGDa0ErwX0LV3y-gBYpfNA) to check which process is invoking remove xattr
> calls.
> It prints the pid, tid and arguments of all removexattr calls.
>
> I have checked for these fops at the protocol/client and posix translators.
>
>
> To run the script ..
>
> 1) install systemtap and dependencies.
> 2) install glusterfs-debuginfo
>
> 3) change the path of the translator in the systemtap script to
> appropriate values for your system
>
> (change "/usr/lib64/glusterfs/3.12dev/xlator/protocol/client.so" and
> "/usr/lib64/glusterfs/3.12dev/xlator/storage/posix.so")
>
> 4) run the script as follows
>
> #stap -v fop_trace.stp
>
> The o/p would look like these .. additionally arguments will also be
> dumped if glusterfs-debuginfo is also installed (i had not done it here.)
> pid-958: 0 glusterfsd(3893):->posix_setxattr
> pid-958:47 glusterfsd(3893):<-posix_setxattr
> pid-966: 0 glusterfsd(5033):->posix_setxattr
> pid-966:57 glusterfsd(5033):<-posix_setxattr
> pid-1423: 0 glusterfs(1431):->client_setxattr
> pid-1423:37 glusterfs(1431):<-client_setxattr
> pid-1423: 0 glusterfs(1431):->client_setxattr
> pid-1423:41 glusterfs(1431):<-client_setxattr
>
> Regards,
>
> Sanoj
>
>
>
>
>
>
>
> On Mon, Jul 10, 2017 at 2:56 PM, Sanoj Unnikrishnan <sunni...@redhat.com>
> wrote:
>
> @ pranith , yes . we can get the pid on all removexattr call and also
> print the backtrace of the glusterfsd process when trigerring removing
> xattr.
>
> I will write the script and reply back.
>
>
>
> On Sat, Jul 8, 2017 at 7:06 AM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
> Ram,
>
>As per the code, self-heal was the only candidate which *can* do
> it. Could you check logs of self-heal daemon and the mount to check if
> there are any metadata heals on root?
>
> +Sanoj
>
> Sanoj,
>
>Is there any systemtap script we can use to detect which process is
> removing these xattrs?
>
>
>
> On Sat, Jul 8, 2017 at 2:58 AM, Ankireddypalle Reddy <are...@commvault.com>
> wrote:
>
> We lost the attributes on all the bricks on servers glusterfs2 and
> glusterfs3 again.
>
>
>
> [root@glusterfs2 Log_Files]# gluster volume info
>
>
>
> Volume Name: StoragePool
>
> Type: Distributed-Disperse
>
> Volume ID: 149e976f-4e21-451c-bf0f-f5691208531f
>
> Status: Started
>
> Number of Bricks: 20 x (2 + 1) = 60
>
> Transport-type: tcp
>
> Bricks:
>
> Brick1: glusterfs1sds:/ws/disk1/ws_brick
>
> Brick2: glusterfs2sds:/ws/disk1/ws_brick
>
> Brick3: glusterfs3sds:/ws/disk1/ws_brick
>
> Brick4: glusterfs1sds:/ws/disk2/ws_brick
>
> Brick5: glusterfs2sds:/ws/disk2/ws_brick
>
> Brick6: glusterfs3sds:/ws/disk2/ws_brick
>
> Brick7: glusterfs1sds:/ws/disk3/ws_brick
>
> Brick8: glusterfs2sds:/ws/disk3/ws_brick
>
> Brick9: glusterfs3sds:/ws/disk3/ws_brick
>
> Brick10: glusterfs1sds:/ws/disk4/ws_brick
>
> Brick11: glusterfs2sds:/ws/disk4/ws_brick
>
> Brick12: glusterfs3sds:/ws/disk4/ws_brick
>
> Brick13: glusterfs1sds:/ws/disk5/ws_brick
>
> Brick14: glusterfs2sds:/ws/disk5/ws_brick
>
> Brick15: glusterfs3sds:/ws/disk5/ws_brick
>
> Brick16: glusterfs1sds:/ws/disk6/ws_brick
>
> Brick17: glusterfs2sds:/ws/disk6/ws_brick
>
> Brick18: glusterfs3sds:/ws/disk6/ws_brick
>
> Brick19: glusterfs1sds:/ws/disk7/ws_brick
>
> Brick20: glusterfs2sds:/ws/disk7/ws_brick
>
> Brick21: glusterfs3sds:/ws/disk7/ws_brick
>
> Brick22: glusterfs1sds:/ws/disk8/ws_brick
&

Re: [Gluster-devel] create restrictions xlator

[Pranith Kumar Karampuri]

On Thu, Jul 13, 2017 at 10:11 AM, Taehwa Lee <alghost@gmail.com> wrote:

> Thank you for response quickly
>
>
> I went through dht_get_du_info before I start developing this.
>
> at that time, I think that this functionality should be independent module.
>
>
> so, I will move this into DHT without new statfs.
>

Let's here from dht folks also what they think about this change before you
make modifications. I included some of the dht folks to the thread.


>
> and then, will suggest it on gerrit !
>
>
> Thank you so much.
>
>
> -
> Taehwa Lee
> Gluesys Co.,Ltd.
> alghost@gmail.com
> +82-10-3420-6114, +82-70-8785-6591
> -----
>
> 2017. 7. 13. 오후 1:06, Pranith Kumar Karampuri <pkara...@redhat.com> 작성:
>
> hey,
>   I went through the patch. I see that statfs is always wound for
> create fop. So number of network operations increase and performance will
> be less even in normal case. I think similar functionality is in DHT, may
> be you should take a look at that?
>
> Check dht_get_du_info() which is used by dht_mknod(). It keeps refreshing
> this info every X seconds. I will let DHT guys comment a bit more about
> this. One more thing to check is if we can have just one implementation
> that satisfied everyone's requirements. i.e. move out this functionality
> from DHT to this xlator or, move the functionality of this xlator into DHT.
>
>
> On Thu, Jul 13, 2017 at 8:18 AM, Taehwa Lee <alghost@gmail.com> wrote:
>
>> Hi all,
>>
>> I’ve been developing a xlator that create is rejected when used capacity
>> of a volume higher than threshold.
>>
>>
>> the reason why I’m doing is that I got problems when LV is used fully.
>>
>> this patch is in the middle of develop.
>>
>> just I want to know whether my approach is pretty correct to satisfy my
>> requirement.
>>
>> so, when you guys have a little spare time, please review my patch and
>> tell me WHATEVER you’re thinking.
>>
>>
>> and If you guys think that it is useful for glusterfs, I’m gonna do
>> process to merge into glusterfs.
>>
>>
>> thanks in advance
>>
>>
>>
>>
>>
>> -
>> Taehwa Lee
>> Gluesys Co.,Ltd.
>> alghost@gmail.com
>> +82-10-3420-6114, +82-70-8785-6591
>> -
>>
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Pranith
>
>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Forgot how to download NetBSD logfiles

[Pranith Kumar Karampuri]

On Fri, Jul 14, 2017 at 9:22 PM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

> hi,
>I am not able to download the "Logs archived in
> http://nbslave74.cloud.gluster.org/archives/logs/
> glusterfs-logs-20170713080233.tgz"
>
> I get the following error:
> archives/logs/glusterfs-logs-20170713080233.tgz
>
This item has not been found

 This was the error :-)

>
> We had to modify something in the URL to get the correct link but now
> either it changed or I don't remember what the modification used to be.
>
> The change I made affects all platforms, so I want to find out why trash.t
> fails consistently on NetBSD with this change.
>
> --
> Pranith
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Forgot how to download NetBSD logfiles

[Pranith Kumar Karampuri]

hi,
   I am not able to download the "Logs archived in
http://nbslave74.cloud.gluster.org/archives/logs/glusterfs-logs-20170713080233.tgz
"

I get the following error:
archives/logs/glusterfs-logs-20170713080233.tgz

We had to modify something in the URL to get the correct link but now
either it changed or I don't remember what the modification used to be.

The change I made affects all platforms, so I want to find out why trash.t
fails consistently on NetBSD with this change.

-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Replicated volume, one slow brick

[Pranith Kumar Karampuri]

Adding gluster-devel

Raghavendra,
 I remember we discussing about handling these kinds of errors by
ping-timer expiry? I may have missed the final decision on how this was
decided to be handled. So asking you again ;-)

On Thu, Jul 13, 2017 at 2:14 PM, Øyvind Krosby  wrote:

> I have been trying to figure out how glusterfs-fuse client will handle it
> when 1 of 3 bricks in a 3-way replica is slower than the others.
>
> It looks like a glusterfs-fuse client will send requests to all 3 bricks
> when accessing a file. But what happens when one of the bricks is not
> responding in time?
>
> We saw an issue when we added external load to the raid volume where the
> brick was located. The disk became 100% busy, and as a result the
> glusterfs-clients hang when they access the volume.
>
> Is there a way to avoid this, and make the clients ask the other two
> bricks for the data when one brick is too slow?
>
> Thanks
>
> Øyvind Krosby
> SRE, Zedge.net
>
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Regarding positioning of nl-cache in gluster client stack

[Pranith Kumar Karampuri]

On Mon, Jul 17, 2017 at 11:31 AM, Krutika Dhananjay 
wrote:

> Hi Poornima and Pranith,
>
> I see that currently glusterd loads nl-cache between stat-prefetch and
> open-behind on the client stack. Were there any specific considerations for
> selecting this position for nl-cache?
>
> I was interested to see the performance impact of loading this translator
> between shard and DHT in the VM store use case stack in terms of reducing
> the number of lookups shard would have to do to figure out if a shard is
> already created or not, since shard does its own management of .shard and
> the files under it.
>
> So with this background, do you see any issues with loading nl-cache above
> DHT in the client stack?
>

Nothing I can think of at the moment.


>
> -Krutika
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Error while mounting gluster volume

[Pranith Kumar Karampuri]

The following generally means it is not able to connect to any of the
glusterds in the cluster.

[1970-01-02 10:54:04.420406] E [glusterfsd-mgmt.c:1818:mgmt_rpc_notify]
0-glusterfsd-mgmt: failed to connect with remote-host: 128.224.95.140
(Success)
[1970-01-02 10:54:04.420422] I [MSGID: 101190]
[event-epoll.c:632:event_dispatch_epoll_worker]
0-epoll: Started thread with index 1
[1970-01-02 10:54:04.420429] I [glusterfsd-mgmt.c:1824:mgmt_rpc_notify]
0-glusterfsd-mgmt: Exhausted all volfile servers


On Thu, Jul 20, 2017 at 4:01 PM, ABHISHEK PALIWAL 
wrote:

> Hi Team,
>
> While mounting the gluster volume using 'mount -t glusterfs' command it is
> getting failed.
>
> When we checked the log file getting the below logs
>
> [1970-01-02 10:54:04.420065] E [MSGID: 101187] 
> [event-epoll.c:391:event_register_epoll]
> 0-epoll: failed to add fd(=7) to epoll fd(=0) [Invalid argument]
> [1970-01-02 10:54:04.420140] W [socket.c:3095:socket_connect] 0-: failed
> to register the event
> [1970-01-02 10:54:04.420406] E [glusterfsd-mgmt.c:1818:mgmt_rpc_notify]
> 0-glusterfsd-mgmt: failed to connect with remote-host: 128.224.95.140
> (Success)
> [1970-01-02 10:54:04.420422] I [MSGID: 101190] 
> [event-epoll.c:632:event_dispatch_epoll_worker]
> 0-epoll: Started thread with index 1
> [1970-01-02 10:54:04.420429] I [glusterfsd-mgmt.c:1824:mgmt_rpc_notify]
> 0-glusterfsd-mgmt: Exhausted all volfile servers
> [1970-01-02 10:54:04.420480] E [MSGID: 101063] 
> [event-epoll.c:550:event_dispatch_epoll_handler]
> 0-epoll: stale fd found on idx=0, gen=0, events=0, slot->gen=2
> [1970-01-02 10:54:04.420511] E [MSGID: 101063] 
> [event-epoll.c:550:event_dispatch_epoll_handler]
> 0-epoll: stale fd found on idx=0, gen=0, events=0, slot->gen=3
> [1970-01-02 10:54:04.420534] E [MSGID: 101063] 
> [event-epoll.c:550:event_dispatch_epoll_handler]
> 0-epoll: stale fd found on idx=0, gen=0, events=0, slot->gen=4
> [1970-01-02 10:54:04.420556] E [MSGID: 101063] 
> [event-epoll.c:550:event_dispatch_epoll_handler]
> 0-epoll: stale fd found on idx=0, gen=0, events=0, slot->gen=5
> [1970-01-02 10:54:04.420566] W [glusterfsd.c:1238:cleanup_and_exit]
> (-->/usr/lib64/libgfrpc.so.0(rpc_clnt_notify-0xb18c) [0x3fff8155e1e4]
> -->/usr/sbin/glusterfs() [0x100103a0] 
> -->/usr/sbin/glusterfs(cleanup_and_exit-0x1beac)
> [0x100097ac] ) 0-: received signum (1), shutting down
> [1970-01-02 10:54:04.420579] E [MSGID: 101063] 
> [event-epoll.c:550:event_dispatch_epoll_handler]
> 0-epoll: stale fd found on idx=0, gen=0, events=0, slot->gen=6
> [1970-01-02 10:54:04.420606] E [MSGID: 101063] 
> [event-epoll.c:550:event_dispatch_epoll_handler]
> 0-epoll: stale fd found on idx=0, gen=0, events=0, slot->gen=7
> [1970-01-02 10:54:04.420635] E [MSGID: 101063] 
> [event-epoll.c:550:event_dispatch_epoll_handler]
> 0-epoll: stale fd found on idx=0, gen=0, events=0, slot->gen=8
> [1970-01-02 10:54:04.420664] E [MSGID: 101063] 
> [event-epoll.c:550:event_dispatch_epoll_handler]
> 0-epoll: stale fd found on idx=0, gen=0, events=0, slot->gen=9
> [1970-01-02 10:54:04.420695] E [MSGID: 101063] 
> [event-epoll.c:550:event_dispatch_epoll_handler]
> 0-epoll: stale fd found on idx=0, gen=0, events=0, slot->gen=10
> [1970-01-02 10:54:04.420722] E [MSGID: 101063] 
> [event-epoll.c:550:event_dispatch_epoll_handler]
> 0-epoll: stale fd found on idx=0, gen=0, events=0, slot->gen=11
>
> for more logs we have attached the mount log file as well.
>
> Could you please help us in to identify the root cause?
>
> --
>
> Regards
> Abhishek Paliwal
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Changing the relative order of read-ahead and open-behind

[Pranith Kumar Karampuri]

On Mon, Jul 24, 2017 at 5:11 PM, Raghavendra G 
wrote:

>
>
> On Fri, Jul 21, 2017 at 6:39 PM, Vijay Bellur  wrote:
>
>>
>> On Fri, Jul 21, 2017 at 3:26 AM, Raghavendra Gowdappa <
>> rgowd...@redhat.com> wrote:
>>
>>> Hi all,
>>>
>>> We've a bug [1], due to which read-ahead is completely disabled when the
>>> workload is read-only. One of the easy fix was to make read-ahead as an
>>> ancestor of open-behind in xlator graph (Currently its a descendant). A
>>> patch has been sent out by Rafi to do the same. As noted in one of the
>>> comments, one flip side of this solution is that small files (which are
>>> eligible to be cached by quick read) are cached twice - once each in
>>> read-ahead and quick-read - wasting up precious memory. However, there are
>>> no other simpler solutions for this issue. If you've concerns on the
>>> approach followed by [2] or have other suggestions please voice them out.
>>> Otherwise, I am planning to merge [2] for lack of better alternatives.
>>>
>>
>>
>> Since the maximum size of files cached by quick-read is 64KB, can we have
>> read-ahead kick in for offsets greater than 64KB?
>>
>
> I got your point. We can enable read-ahead only for files whose size is
> greater than the size eligible for caching quick-read. IOW, read-ahead gets
> disabled if file size is less than 64KB. Thanks for the suggestion.
>

I added a comment on the patch to move the xlators in reverse to the way
the patch is currently doing. Milind I think implemented it. Will that lead
to any problem?


>
>
>>
>> Thanks,
>> Vijay
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Raghavendra G
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release 3.12: Status of features (Require responses!)

[Pranith Kumar Karampuri]

On Sat, Jul 22, 2017 at 1:36 AM, Shyam  wrote:

> Hi,
>
> Prepare for a lengthy mail, but needed for the 3.12 release branching, so
> here is a key to aid the impatient,
>
> Key:
> 1) If you asked for an exception to a feature (meaning delayed backport to
> 3.12 branch post branching for the release) see "Section 1"
>   - Handy list of nick's that maybe interested in this:
> - @pranithk, @sunilheggodu, @aspandey, @amarts, @kalebskeithley,
> @kshlm (IPv6), @jdarcy (Halo Hybrid)
>
> 2) If you have/had a feature targeted for 3.12 and have some code posted
> against the same, look at "Section 2" AND we want to hear back from you!
>   - Handy list of nick's that should be interested in this:
> - @csabahenk, @nixpanic, @aravindavk, @amarts, @kotreshhr,
> @soumyakoduri
>
> 3) If you have/had a feature targeted for 3.12 and have posted no code
> against the same yet, see "Section 3", your feature is being dropped from
> the release.
>   - Handy list of nick's that maybe interested in this:
> - @sanoj-unnikrishnan, @aravindavk, @kotreshhr, @amarts, @jdarcy,
> @avra (people who filed the issue)
>
> 4) Finally, if you do not have any features for the release pending,
> please help others out reviewing what is still pending, here [1] is a quick
> link to those reviews.
>
> Sections:
>
> **Section 1:**
> Exceptions granted to the following features: (Total: 8)
> Reasons:
>   - Called out in the mail sent for noting exceptions and feature status
> for 3.12
>   - Awaiting final changes/decision from a few Facebook patches
>
> Issue list:
> - Implement an xlator to delay fops
>   - https://github.com/gluster/glusterfs/issues/257
>
> - Implement parallel writes feature on EC volume
>   - https://github.com/gluster/glusterfs/issues/251


Looks like it will take one more week after this, what do you suggest?


>
>
> - DISCARD support with EC
>   - https://github.com/gluster/glusterfs/issues/254
>
> - Cache last stripe of an EC volume while write is going on
>   - https://github.com/gluster/glusterfs/issues/256
>

Looks like it will take 2 more week after this, what do you suggest?


> - gfid-path by default
>   - https://github.com/gluster/glusterfs/issues/139
>
> - allow users to enable used of localtime instead of UTC for log entries
>   - https://github.com/gluster/glusterfs/issues/272
>
> - Halo translator: Hybrid mode
>   - https://github.com/gluster/glusterfs/issues/217
>
> - [RFE] Improve IPv6 support in GlusterFS
>   - https://github.com/gluster/glusterfs/issues/192
>
> **Section 2:**
> Issues needing some further clarity: (Total: 6)
> Reason:
>   - There are issues here, for which code is already merged (or submitted)
> and issue is still open. This is the right state for an issue to be in this
> stage of the release, as documentation or release-notes would possibly be
> still pending, which will finally close the issue (or rather mark it fixed)
>   - BUT, without a call out from the contributors that required code is
> already merged in, it is difficult to assess if the issue should qualify
> for the release
>
> Issue list:
> - [RFE] libfuse rebase to latest?
>   - https://github.com/gluster/glusterfs/issues/153
>   - @csabahenk is this all done?
>
> - Decide what to do with glfs_ipc() in libgfapi
>   - https://github.com/gluster/glusterfs/issues/269
>   - @nixpanic I assume there is more than just test case disabling for
> this, is this expected to happen by 3.12?
>
> - Structured log format support for gf_log and gf_msg
>   - https://github.com/gluster/glusterfs/issues/240
>   - @aravindavk this looks done, anything code wise pending here?
>
> - xxhash: Add xxhash library
>   - https://github.com/gluster/glusterfs/issues/253
>   - @kotreshhr this looks done, anything code wise pending here?
>
> - posix: provide option to handle 'statfs()' properly when more than 1
> brick is exported from 1 node
>   - https://github.com/gluster/glusterfs/issues/241
>   - @amarts patch is still awaiting reviews, should this be tracked as an
> exception?
>
> - gfapi to support leases and lock-owner
>   - https://github.com/gluster/glusterfs/issues/213
>   - @soumyakoduri I do not see work progressing on the patches provided,
> should this be dropped from 3.12?
>
> **Section 3:**
> Issues moved out of the 3.12 Milestone: (Total: 8)
> Reasons:
>   - No commits visible against the github issue
>   - No commits against 'master' branch visible on the github issue
>
> Further changes:
>   - No new milestone assigned, IOW not moved to 4.0 by default, hence
> contributors working on these features would need to rekindle conversations
> on including the same in 4.0 on the ML or on the issue itself.
>
> Issue List:
> - [RFE] Syslog alert when Geo-rep worker is faulty for a configurable time
>   https://github.com/gluster/glusterfs/issues/226
>
> - [RFE] Geo-rep: Sync metadata operations as part of sync itself
> (rsync/tar-ssh)
>   https://github.com/gluster/glusterfs/issues/222
>
> - 

Re: [Gluster-devel] Disperse volume : Sequential Writes

[Pranith Kumar Karampuri]

Ashish, Xavi,
   I think it is better to implement this change as a separate
read-after-write caching xlator which we can load between EC and client
xlator. That way EC will not get a lot more functionality than necessary
and may be this xlator can be used somewhere else in the stack if possible.

On Fri, Jun 16, 2017 at 4:19 PM, Ashish Pandey <aspan...@redhat.com> wrote:

>
> I think it should be done as we have agreement on basic design.
>
> --
> *From: *"Pranith Kumar Karampuri" <pkara...@redhat.com>
> *To: *"Xavier Hernandez" <xhernan...@datalab.es>
> *Cc: *"Ashish Pandey" <aspan...@redhat.com>, "Gluster Devel" <
> gluster-devel@gluster.org>
> *Sent: *Friday, June 16, 2017 3:50:09 PM
> *Subject: *Re: [Gluster-devel] Disperse volume : Sequential Writes
>
>
>
>
> On Fri, Jun 16, 2017 at 3:12 PM, Xavier Hernandez <xhernan...@datalab.es>
> wrote:
>
>> On 16/06/17 10:51, Pranith Kumar Karampuri wrote:
>>
>>>
>>>
>>> On Fri, Jun 16, 2017 at 12:02 PM, Xavier Hernandez
>>> <xhernan...@datalab.es <mailto:xhernan...@datalab.es>> wrote:
>>>
>>> On 15/06/17 11:50, Pranith Kumar Karampuri wrote:
>>>
>>>
>>>
>>> On Thu, Jun 15, 2017 at 11:51 AM, Ashish Pandey
>>> <aspan...@redhat.com <mailto:aspan...@redhat.com>
>>> <mailto:aspan...@redhat.com <mailto:aspan...@redhat.com>>>
>>> wrote:
>>>
>>> Hi All,
>>>
>>> We have been facing some issues in disperse (EC) volume.
>>> We know that currently EC is not good for random IO as it
>>> requires
>>> READ-MODIFY-WRITE fop
>>> cycle if an offset and offset+length falls in the middle of
>>> strip size.
>>>
>>> Unfortunately, it could also happen with sequential writes.
>>> Consider an EC volume with configuration  4+2. The stripe
>>> size for
>>> this would be 512 * 4 = 2048. That is, 2048 bytes of user
>>> data
>>> stored in one stripe.
>>> Let's say 2048 + 512 = 2560 bytes are already written on this
>>> volume. 512 Bytes would be in second stripe.
>>> Now, if there are sequential writes with offset 2560 and of
>>> size 1
>>> Byte, we have to read the whole stripe, encode it with 1
>>> Byte and
>>> then again have to write it back.
>>> Next, write with offset 2561 and size of 1 Byte will again
>>> READ-MODIFY-WRITE the whole stripe. This is causing bad
>>> performance.
>>>
>>> There are some tools and scenario's where such kind of load
>>> is
>>> coming and users are not aware of that.
>>> Example: fio and zip
>>>
>>> Solution:
>>> One possible solution to deal with this issue is to keep
>>> last stripe
>>> in memory.
>>> This way, we need not to read it again and we can save READ
>>> fop
>>> going over the network.
>>> Considering the above example, we have to keep last 2048
>>> bytes
>>> (maximum)  in memory per file. This should not be a big
>>> deal as we already keep some data like xattr's and size info
>>> in
>>> memory and based on that we take decisions.
>>>
>>> Please provide your thoughts on this and also if you have
>>> any other
>>> solution.
>>>
>>>
>>> Just adding more details.
>>> The stripe will be in memory only when lock on the inode is
>>> active.
>>>
>>>
>>> I think that's ok.
>>>
>>> One
>>> thing we are yet to decide on is: do we want to read the stripe
>>> everytime we get the lock or just after an extending write is
>>> performed.
>>> I am thinking keeping the stripe in memory just after an
>>> extending write
>>> is better as it doesn't involve extra network operation.
>>>
>>>
>>> I wouldn't read the last stripe unconditionally every time we lock
>>> the inode. There's no benefit at all on random

Re: [Gluster-devel] geo-rep regression because of node-uuid change

[Pranith Kumar Karampuri]

Xavi,
  Now that the change has been reverted, we can resume this discussion
and decide on the exact format that considers, tier, dht, afr, ec. People
working geo-rep/dht/afr/ec had an internal discussion and we all agreed
that this proposal would be a good way forward. I think once we agree on
the format and decide on the initial encoding/decoding functions of the
xattr and this change is merged, we can send patches on afr/ec/dht and
geo-rep to take it to closure.

Could you propose the new format you have in mind that considers all of the
xlators?



On Wed, Jun 21, 2017 at 2:08 PM, Karthik Subrahmanya <ksubr...@redhat.com>
wrote:

>
>
> On Wed, Jun 21, 2017 at 1:56 PM, Xavier Hernandez <xhernan...@datalab.es>
> wrote:
>
>> That's ok. I'm currently unable to write a patch for this on ec.
>
> Sunil is working on this patch.
>
> ~Karthik
>
>> If no one can do it, I can try to do it in 6 - 7 hours...
>>
>> Xavi
>>
>>
>> On Wednesday, June 21, 2017 09:48 CEST, Pranith Kumar Karampuri <
>> pkara...@redhat.com> wrote:
>>
>>
>>
>>
>> On Wed, Jun 21, 2017 at 1:00 PM, Xavier Hernandez <xhernan...@datalab.es>
>> wrote:
>>>
>>> I'm ok with reverting node-uuid content to the previous format and
>>> create a new xattr for the new format. Currently, only rebalance will use
>>> it.
>>>
>>> Only thing to consider is what can happen if we have a half upgraded
>>> cluster where some clients have this change and some not. Can rebalance
>>> work in this situation ? if so, could there be any issue ?
>>
>>
>> I think there shouldn't be any problem, because this is in-memory xattr
>> so layers below afr/ec will only see node-uuid xattr.
>> This also gives us a chance to do whatever we want to do in future with
>> this xattr without any problems about backward compatibility.
>>
>> You can check https://review.gluster.org/#/c
>> /17576/3/xlators/cluster/afr/src/afr-inode-read.c@1507 for how karthik
>> implemented this in AFR (this got merged accidentally yesterday, but looks
>> like this is what we are settling on)
>>
>>
>>>
>>> Xavi
>>>
>>>
>>> On Wednesday, June 21, 2017 06:56 CEST, Pranith Kumar Karampuri <
>>> pkara...@redhat.com> wrote:
>>>
>>>
>>>
>>>
>>> On Wed, Jun 21, 2017 at 10:07 AM, Nithya Balachandran <
>>> nbala...@redhat.com> wrote:
>>>>
>>>>
>>>> On 20 June 2017 at 20:38, Aravinda <avish...@redhat.com> wrote:
>>>>>
>>>>> On 06/20/2017 06:02 PM, Pranith Kumar Karampuri wrote:
>>>>>
>>>>> Xavi, Aravinda and I had a discussion on #gluster-dev and we agreed to
>>>>> go with the format Aravinda suggested for now and in future we wanted some
>>>>> more changes for dht to detect which subvolume went down came back up, at
>>>>> that time we will revisit the solution suggested by Xavi.
>>>>>
>>>>> Susanth is doing the dht changes
>>>>> Aravinda is doing geo-rep changes
>>>>>
>>>>> Done. Geo-rep patch sent for review https://review.gluster.org/17582
>>>>>
>>>>>
>>>>
>>>> The proposed changes to the node-uuid behaviour (while good) are going
>>>> to break tiering . Tiering changes will take a little more time to be coded
>>>> and tested.
>>>>
>>>> As this is a regression for 3.11 and a blocker for 3.11.1, I suggest we
>>>> go back to the original node-uuid behaviour for now so as to unblock the
>>>> release and target the proposed changes for the next 3.11 releases.
>>>>
>>>
>>> Let me see if I understand the changes correctly. We are restoring the
>>> behavior of node-uuid xattr and adding a new xattr for parallel rebalance
>>> for both afr and ec, correct? Otherwise that is one more regression. If
>>> yes, we will also wait for Xavi's inputs. Jeff accidentally merged the afr
>>> patch yesterday which does these changes. If everyone is in agreement, we
>>> will leave it as is and add similar changes in ec as well. If we are not in
>>> agreement, then we will let the discussion progress :-)
>>>
>>>
>>>>
>>>>
>>>> Regards,
>>>> Nithya
>>>>
>>>>> --
>>>>> Aravinda
>>>>>
>>>>>
>>>>>
>>>>> Thanks to all of you guys for the discussio

Re: [Gluster-devel] Suggest how to recognize the time when heal is triggered by using events

[Pranith Kumar Karampuri]

patch looks good to me. Do you want to send it on gerrit?

On Wed, Jul 5, 2017 at 6:49 AM, Taehwa Lee  wrote:

> Hello, Karampuri.
>
>
> I've been developing products using glusterfs for 2 years almost with my
> co-workers.
>
> I got a problem that the products cannot recognize the time when heal is
> triggered.
>
> I think healing affect the performance of glusterfs volume definitely.
>
> So, we should monitor whether healing is in progress or not.
>
>
> To monitor it, event api is one of the best way, I guess.
>
> So I have created the issue including patch for it on bugzilla;
> https://bugzilla.redhat.com/show_bug.cgi?id=1467543
>
>
>
> Can I get some feedbacks?
>
> Thanks in advance.
>
>
> Best regards.
>
>
> -
> 이 태 화
> Taehwa Lee
> Gluesys Co.,Ltd.
> alghost@gmail.com
> 010-3420-6114, 070-8785-6591
> -
>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Disperse volume : Sequential Writes

[Pranith Kumar Karampuri]

On Tue, Jul 4, 2017 at 1:39 PM, Xavier Hernandez <xhernan...@datalab.es>
wrote:

> Hi Pranith,
>
> On 03/07/17 05:35, Pranith Kumar Karampuri wrote:
>
>> Ashish, Xavi,
>>I think it is better to implement this change as a separate
>> read-after-write caching xlator which we can load between EC and client
>> xlator. That way EC will not get a lot more functionality than necessary
>> and may be this xlator can be used somewhere else in the stack if
>> possible.
>>
>
> while this seems a good way to separate functionalities, it has a big
> problem. If we add a caching xlator between ec and *all* of its subvolumes,
> it will only be able to cache encoded data. So, when ec needs the "cached"
> data, it will need to issue a request to each of its subvolumes and compute
> the decoded data before being able to use it, so we don't avoid the
> decoding overhead.
>
> Also, if we want to make the xlator generic, it will probably cache a lot
> more data than ec really needs. Increasing memory footprint considerably
> for no real use.
>
> Additionally, this new xlator will need to guarantee that the cached data
> is current, so it will need its own locking logic (that would be another
> copy of the existing logic in one of the current xlators) which is
> slow and difficult to maintain, or it will need to intercept and reuse
> locking calls from parent xlators, which can be quite complex since we have
> multiple xlator levels where locks can be taken, not only ec.
>
> This is a relatively simple change to make inside ec, but a very complex
> change (IMO) if we want to do it as a stand-alone xlator and be generic
> enough to be reused and work safely in other places of the stack.
>
> If we want to separate functionalities I think we should create a new
> concept of xlator which is transversal to the "traditional" xlator stack.
>
> Current xlators are linear in the sense that each one operates only at one
> place (it can be moved by reconfiguration, but once instantiated, it always
> work at the same place) and passes data to the next one.
>
> A transversal xlator (or maybe a service xlator would be better) would be
> one not bound to any place of the stack, but could be used by all other
> xlators to implement some service, like caching, multithreading, locking,
> ... these are features that many xlators need but cannot use easily (nor
> efficiently) if they are implicitly implemented in some specific place of
> the stack outside its control.
>
> The transaction framework we already talked, could be though as one of
> these service xlators. Multithreading could also benefit of this approach
> because xlators would have more control about what things can be processed
> by a background thread and which ones not. Probably there are other
> features that could benefit from this approach.
>
> In the case of brick multiplexing, if some xlators are removed from each
> stack and loaded as global services, most probably the memory footprint
> will be lower and the resource usage more optimized.
>

I like the service xlator approach. But I don't think we have enough time
to make it operational in the short term. Let us go with implementation of
this feature in EC for now. I didn't realize the extra cost of decoding
when I thought about the separation. So I guess we will stick to the old
idea for now.


>
> Just an idea...
>
> Xavi
>
>
>> On Fri, Jun 16, 2017 at 4:19 PM, Ashish Pandey <aspan...@redhat.com
>> <mailto:aspan...@redhat.com>> wrote:
>>
>>
>> I think it should be done as we have agreement on basic design.
>>
>> 
>> 
>> *From: *"Pranith Kumar Karampuri" <pkara...@redhat.com
>> <mailto:pkara...@redhat.com>>
>> *To: *"Xavier Hernandez" <xhernan...@datalab.es
>> <mailto:xhernan...@datalab.es>>
>> *Cc: *"Ashish Pandey" <aspan...@redhat.com
>> <mailto:aspan...@redhat.com>>, "Gluster Devel"
>> <gluster-devel@gluster.org <mailto:gluster-devel@gluster.org>>
>> *Sent: *Friday, June 16, 2017 3:50:09 PM
>> *Subject: *Re: [Gluster-devel] Disperse volume : Sequential Writes
>>
>>
>>
>>
>> On Fri, Jun 16, 2017 at 3:12 PM, Xavier Hernandez
>> <xhernan...@datalab.es <mailto:xhernan...@datalab.es>> wrote:
>>
>> On 16/06/17 10:51, Pranith Kumar Karampuri wrote:
>>
>>
>>
>> On Fri, Jun 16, 2017 at 12:02 PM, Xavier Hernandez
>> <xhernan...@datalab.es <ma

Re: [Gluster-devel] geo-rep regression because of node-uuid change

[Pranith Kumar Karampuri]

On Tue, Jul 4, 2017 at 2:26 PM, Xavier Hernandez <xhernan...@datalab.es>
wrote:

> Hi Pranith,
>
> On 03/07/17 08:33, Pranith Kumar Karampuri wrote:
>
>> Xavi,
>>   Now that the change has been reverted, we can resume this
>> discussion and decide on the exact format that considers, tier, dht,
>> afr, ec. People working geo-rep/dht/afr/ec had an internal discussion
>> and we all agreed that this proposal would be a good way forward. I
>> think once we agree on the format and decide on the initial
>> encoding/decoding functions of the xattr and this change is merged, we
>> can send patches on afr/ec/dht and geo-rep to take it to closure.
>>
>> Could you propose the new format you have in mind that considers all of
>> the xlators?
>>
>
> My idea was to create a new xattr not bound to any particular function but
> which could give enough information to be used in many places.
>
> Currently we have another attribute called glusterfs.pathinfo that returns
> hierarchical information about the location of a file. Maybe we can extend
> this to unify all these attributes into a single feature that could be used
> for multiple purposes.
>
> Since we have time to discuss it, I would like to design it with more
> information than we already talked.
>
> First of all, the amount of information that this attribute can contain is
> quite big if we expect to have volumes with thousands of bricks. Even in
> the most simple case of returning only an UUID, we can easily go beyond the
> limit of 64KB.
>
> Consider also, for example, what shard should return when pathinfo is
> requested for a file. Probably it should return a list of shards, each one
> with all its associated pathinfo. We are talking about big amounts of data
> here.
>
> I think this kind of information doesn't fit very well in an extended
> attribute. Another think to consider is that most probably the requester of
> the data only needs a fragment of it, so we are generating big amounts of
> data only to be parsed and reduced later, dismissing most of it.
>
> What do you think about using a very special virtual file to manage all
> this information ? it could be easily read using normal read fops, so it
> could manage big amounts of data easily. Also, accessing only to some parts
> of the file we could go directly where we want, avoiding the read of all
> remaining data.
>
> A very basic idea could be this:
>
> Each xlator would have a reserved area of the file. We can reserve up to
> 4GB per xlator (32 bits). The remaining 32 bits of the offset would
> indicate the xlator we want to access.
>
> At offset 0 we have generic information about the volume. One of the the
> things that this information should include is a basic hierarchy of the
> whole volume and the offset for each xlator.
>
> After reading this, the user will seek to the desired offset and read the
> information related to the xlator it is interested in.
>
> All the information should be stored in a format easily extensible that
> will be kept compatible even if new information is added in the future (for
> example doing special mappings of the 32 bits offsets reserved for the
> xlator).
>
> For example we can reserve the first megabyte of the xlator area to have a
> mapping of attributes with its respective offset.
>
> I think that using a binary format would simplify all this a lot.
>
> Do you think this is a way to explore or should I stop wasting time here ?
>

I think this just became a very big feature :-). Shall we just live with it
the way it is now?


>
> Xavi
>
>
>>
>>
>> On Wed, Jun 21, 2017 at 2:08 PM, Karthik Subrahmanya
>> <ksubr...@redhat.com <mailto:ksubr...@redhat.com>> wrote:
>>
>>
>>
>> On Wed, Jun 21, 2017 at 1:56 PM, Xavier Hernandez
>> <xhernan...@datalab.es <mailto:xhernan...@datalab.es>> wrote:
>>
>> That's ok. I'm currently unable to write a patch for this on ec.
>>
>> Sunil is working on this patch.
>>
>> ~Karthik
>>
>> If no one can do it, I can try to do it in 6 - 7 hours...
>>
>> Xavi
>>
>>
>> On Wednesday, June 21, 2017 09:48 CEST, Pranith Kumar Karampuri
>> <pkara...@redhat.com <mailto:pkara...@redhat.com>> wrote:
>>
>>
>>>
>>> On Wed, Jun 21, 2017 at 1:00 PM, Xavier Hernandez
>>> <xhernan...@datalab.es <mailto:xhernan...@datalab.es>> wrote:
>>>
>>> I'm ok with reverting node-uuid content to the previous
>>> format and create a new xattr for th

Re: [Gluster-devel] Glusto failures with dispersed volumes + Samba

[Pranith Kumar Karampuri]

On Thu, Jun 29, 2017 at 6:49 PM, Anoop C S  wrote:

> On Thu, 2017-06-29 at 16:35 +0530, Nigel Babu wrote:
> > Hi Pranith and Xavi,
> >
> > We seem to be running into a problem with glusto tests when we try to
> run them against dispersed
> > volumes over a CIFS mount[1].
>
> Is this a new test case? If not was it running successfully before?
>
> > You can find the logs attached to the job [2].
>
> VFS stat call failures are seen in Samba logs:
>
> [2017/06/29 11:01:55.959374,  0] ../source3/modules/vfs_
> glusterfs.c:870(vfs_gluster_stat)
>   glfs_stat(.) failed: Invalid argument
>
> I could also see the following errors(repeatedly..) in glusterfs client
> logs:
>
> [2017-06-29 10:33:43.031198] W [MSGID: 122019]
> [ec-helpers.c:412:ec_loc_gfid_check] 0-
> testvol_distributed-dispersed-disperse-0: Mismatching GFID's in loc
> [2017-06-29 10:33:43.031303] I [MSGID: 109094] 
> [dht-common.c:1016:dht_revalidate_cbk]
> 0-
> testvol_distributed-dispersed-dht: Revalidate: subvolume
> testvol_distributed-dispersed-disperse-0
> for /user11 (gfid = 665c515b-3940-480f-af7c-6aaf37731eaa) returned -1
> [Invalid argument]
>

This log basically says that EC received loc which has different gfids in
loc->inode->gfid and loc->gfid.


>
> > I've triggered a fresh job[3] to confirm that it only fails in these
> particular conditions and
> > certainly seems to be the case. The job is currently ongoing, so you may
> want to take a look when
> > you get some time how this job went.
> >
> > Let me know if you have any questions or need more debugging
> information.
> >
> > [1]: https://ci.centos.org/job/gluster_glusto/325/testReport/
> > [2]: https://ci.centos.org/job/gluster_glusto/325/artifact/
> > [3]: https://ci.centos.org/job/gluster_glusto/326/console
> >
> >
> > ___
> > Gluster-devel mailing list
> > Gluster-devel@gluster.org
> > http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Announcing release 3.11 : Scope, schedule and feature tracking

[Pranith Kumar Karampuri]

On Thu, Apr 13, 2017 at 8:17 PM, Shyam  wrote:

> On 02/28/2017 10:17 AM, Shyam wrote:
>
>> Hi,
>>
>> With release 3.10 shipped [1], it is time to set the dates for release
>> 3.11 (and subsequently 4.0).
>>
>> This mail has the following sections, so please read or revisit as needed,
>>   - Release 3.11 dates (the schedule)
>>   - 3.11 focus areas
>>
>
> Pinging the list on the above 2 items.
>
> *Release 3.11 dates:*
>> Based on our release schedule [2], 3.11 would be 3 months from the 3.10
>> release and would be a Short Term Maintenance (STM) release.
>>
>> This puts 3.11 schedule as (working from the release date backwards):
>> - Release: May 30th, 2017
>> - Branching: April 27th, 2017
>>
>
> Branching is about 2 weeks away, other than the initial set of overflow
> features from 3.10 nothing else has been raised on the lists and in github
> as requests for 3.11.
>
> So, a reminder to folks who are working on features, to raise the relevant
> github issue for the same, and post it to devel list for consideration in
> 3.11 (also this helps tracking and ensuring we are waiting for the right
> things at the time of branching).
>
>
>> *3.11 focus areas:*
>> As maintainers of gluster, we want to harden testing around the various
>> gluster features in this release. Towards this the focus area for this
>> release are,
>>
>> 1) Testing improvements in Gluster
>>   - Primary focus would be to get automated test cases to determine
>> release health, rather than repeating a manual exercise every 3 months
>>   - Further, we would also attempt to focus on maturing Glusto[7] for
>> this, and other needs (as much as possible)
>>
>> 2) Merge all (or as much as possible) Facebook patches into master, and
>> hence into release 3.11
>>   - Facebook has (as announced earlier [3]) started posting their
>> patches mainline, and this needs some attention to make it into master
>>
>>
> Further to the above, we are also considering the following features for
> this release, request feature owners to let us know if these are actively
> being worked on and if these will make the branching dates. (calling out
> folks that I think are the current feature owners for the same)
>
> 1) Halo - Initial Cut (@pranith)
>

Sorry for the delay in response. Due to some other work engagements, I
couldn't spend time on this, I think I can get this done if there is one
week grace period, by 5thMay. Or I can get this done for 3.12.0. Do let me
know what you think.


> 2) IPv6 support (@kaushal)
> 3) Negative lookup (@poornima)
> 4) Parallel Readdirp - More changes to default settings. (@poornima, @du)
>
>
> [1] 3.10 release announcement:
>> http://lists.gluster.org/pipermail/gluster-devel/2017-Februa
>> ry/052188.html
>>
>> [2] Gluster release schedule:
>> https://www.gluster.org/community/release-schedule/
>>
>> [3] Mail regarding facebook patches:
>> http://lists.gluster.org/pipermail/gluster-devel/2016-Decemb
>> er/051784.html
>>
>> [4] Release scope: https://github.com/gluster/glusterfs/projects/1
>>
>> [5] glusterfs github issues: https://github.com/gluster/glusterfs/issues
>>
>> [6] github issues for features and major fixes:
>> https://hackmd.io/s/BkgH8sdtg#
>>
>> [7] Glusto tests: https://github.com/gluster/glusto-tests
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Need inputs on patch #17985

[Pranith Kumar Karampuri]

Raghavendra,
As Ashish mentioned, there aren't any known problems if upper xlators
don't send lookups in EC at the moment.

On Wed, Aug 23, 2017 at 9:07 AM, Ashish Pandey <aspan...@redhat.com> wrote:

> Raghvendra,
>
> I have provided my comment on this patch.
> I think EC will not have any issue with this approach.
> However, I would welcome comments from Xavi and Pranith too for any side
> effects which I may not be able to foresee.
>
> Ashish
>
> --
> *From: *"Raghavendra Gowdappa" <rgowd...@redhat.com>
> *To: *"Ashish Pandey" <aspan...@redhat.com>
> *Cc: *"Pranith Kumar Karampuri" <pkara...@redhat.com>, "Xavier Hernandez"
> <xhernan...@datalab.es>, "Gluster Devel" <gluster-devel@gluster.org>
> *Sent: *Wednesday, August 23, 2017 8:29:48 AM
> *Subject: *Need inputs on patch #17985
>
>
> Hi Ashish,
>
> Following are the blockers for making a decision on whether patch [1] can
> be merged or not:
> * Evaluation of dentry operations (like rename etc) in dht
> * Whether EC works fine if a non-lookup fop (like open(dir), stat, chmod
> etc) hits EC without a single lookup performed on file/inode
>
> Can you please comment on the patch? I'll take care of dht part.
>
> [1] https://review.gluster.org/#/c/17985/
>
> regards,
> Raghavendra
>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Questions on github

[Pranith Kumar Karampuri]

hi,
Wanted to know what people feel about asking/answering questions on
github.com, at the moment we are only using github for RFEs, I am wondering
if it would be fine to open it for questions too. Main benefit I see is
that it is easier to see open-questions at a glance and easy to direct
someone to the question/answer in future. It is a bit cumbersome to browse
through the thread on mailing list compared to github IMHO.

-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Questions on github

[Pranith Kumar Karampuri]

On Tue, May 9, 2017 at 3:18 PM, Amar Tumballi <atumb...@redhat.com> wrote:

> I personally prefer github questions than mailing list, because a valid
> question can later become a reason for a new feature. Also, as you said, we
> can 'assignee' a question and if we start with bug triage we can also make
> sure at least we respond to questions which is pending.
>
> A note of caution, i would like to keep github for more code / feature
> related questions than that of setup related questions.
>

Yeah, I was thinking for feature related questions which can turn into
bugs/features/documentation we can take this route. We can always encourage
them to post on gluster-users and close the question if it doesn't fall in
the category.


>
>
> Regards,
> Amar
>
> On Tue, May 9, 2017 at 2:57 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>> hi,
>> Wanted to know what people feel about asking/answering questions on
>> github.com, at the moment we are only using github for RFEs, I am
>> wondering if it would be fine to open it for questions too. Main benefit I
>> see is that it is easier to see open-questions at a glance and easy to
>> direct someone to the question/answer in future. It is a bit cumbersome to
>> browse through the thread on mailing list compared to github IMHO.
>>
>> --
>> Pranith
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Amar Tumballi (amarts)
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] 120k context switches on GlsuterFS nodes

[Pranith Kumar Karampuri]

+ gluster-devel

On Wed, May 17, 2017 at 10:50 PM, mabi  wrote:

> I don't know exactly what kind of context-switches it was but what I know
> is that it is the "cs" number under "system" when you run vmstat.
>
> Also I use the percona linux monitoring template for cacti (
> https://www.percona.com/doc/percona-monitoring-plugins/
> LATEST/cacti/linux-templates.html) which monitors context switches too.
> If that's of any use interrupts where also quite high during that time with
> peaks up to 50k interrupts.
>
>
>
>  Original Message 
> Subject: Re: [Gluster-users] 120k context switches on GlsuterFS nodes
> Local Time: May 17, 2017 2:37 AM
> UTC Time: May 17, 2017 12:37 AM
> From: ravishan...@redhat.com
> To: mabi , Gluster Users 
>
>
> On 05/16/2017 11:13 PM, mabi wrote:
>
> Today I even saw up to 400k context switches for around 30 minutes on my
> two nodes replica... Does anyone else have so high context switches on
> their GlusterFS nodes?
>
> I am wondering what is "normal" and if I should be worried...
>
>
>
>
>  Original Message 
> Subject: 120k context switches on GlsuterFS nodes
> Local Time: May 11, 2017 9:18 PM
> UTC Time: May 11, 2017 7:18 PM
> From: m...@protonmail.ch
> To: Gluster Users  
>
> Hi,
>
> Today I noticed that for around 50 minutes my two GlusterFS 3.8.11 nodes
> had a very high amount of context switches, around 120k. Usually the
> average is more around 1k-2k. So I checked what was happening and there
> where just more users accessing (downloading) their files at the same time.
> These are directories with typical cloud files, which means files of any
> sizes ranging from a few kB to MB and a lot of course.
>
> Now I never saw such a high number in context switches in my entire life
> so I wanted to ask if this is normal or to be expected? I do not find any
> signs of errors or warnings in any log files.
>
>
> What context switch are you referring to (syscalls context-switch on the
> bricks?) ? How did you measure this?
> -Ravi
>
> My volume is a replicated volume on two nodes with ZFS as filesystem
> behind and the volume is mounted using FUSE on the client (the cloud
> server). On that cloud server the glusterfs process was using quite a lot
> of system CPU but that server (VM) only has 2 vCPUs so maybe I should
> increase the number of vCPUs...
>
> Any ideas or recommendations?
>
>
>
> Regards,
> M.
>
>
>
>
> ___
> Gluster-users mailing 
> listGluster-users@gluster.orghttp://lists.gluster.org/mailman/listinfo/gluster-users
>
>
>
>
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Suggestion to optimize posix_getxattr call

[Pranith Kumar Karampuri]

yeah +1 from me too.

On Mon, May 15, 2017 at 2:56 PM, Mohit Agrawal  wrote:

> Hi,
>
>   I was just checking of posix_getxattr code to debug of my one problem.I
> have found scope of improvement in
>   this function to execute system call in better way.As of now
> function(posix_getxattr) is calling system
>   calls (sys_lgetxattr) two times to get the value of xattr or in case of
> list of xattr it calls multiple times
>
>  1) In first time it get the buffer size required to store the value.
>  call "size = sys_lgetxattr (real_path, key, NULL, 0);"
>  2) In second time it calls the sys_lgetxattr with buffer after allocate
> the buffer size
>  sys_lgetxattr (real_path, key, value, size);
>
>   In the same way function is calling for listxattr also.I think we can
> optimise it as like below
>   declare buffer buf[8192](size can be double to this also)
>   1) Call size = sys_lgetxattr (real_path,key,buf,8192)
>   2) if size == -1 and errono == ERANGE then we need to call systemcalls
> in old way like above otherwise
>  we don't need to do anything.
>
>   In the case of failure we need to call systemcall 3 times while buffer
> is more than our declared buffer
>   size otherwise in most of the cases we need to call it only once.
>
> Please share your input on this, appreciate your input.
>
> Regards
> Mohit Agrawal
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] tests/basic/afr/gfid-mismatch-resolution-with-fav-child-policy.t - regression failures

[Pranith Kumar Karampuri]

On Wed, May 17, 2017 at 4:34 PM, Ravishankar N <ravishan...@redhat.com>
wrote:

> On 05/17/2017 04:09 PM, Pranith Kumar Karampuri wrote:
>
> karthik, Ravi,
>  What is the plan to bring it back? Did you guys find RC for the
> failure?
>
> Are you referring to gfid-mismatch-resolution-with-fav-child-policy.t? I
> already mentioned the RCA in the patch I linked to earlier in this thread?
>

Ah! missed that. Thanks. We can also use self-heald to do the healing and
verify that heals were performed correctly. But it is fine to wait for
karthik's next patch.


>
> On Mon, May 15, 2017 at 10:52 AM, Ravishankar N <ravishan...@redhat.com>
> wrote:
>
>> On 05/12/2017 03:33 PM, Atin Mukherjee wrote:
>>
>> tests/basic/afr/add-brick-self-heal.t
>> <http://git.gluster.org/cgit/glusterfs.git/tree/tests/basic/afr/add-brick-self-heal.t>
>> is the 2nd in the list.
>>
>>
>> All failures (https://fstat.gluster.org/weeks/1/failure/2) are in netbsd
>> and looks like an issue with the slaves.
>> Most of the runs have this error:
>>
>> [07:29:32] Running tests in file ./tests/basic/afr/add-brick-self-heal.t
>> volume create: patchy: failed: Host nbslave70.cloud.gluster.org is not in 
>> 'Peer in Cluster' state
>>
>>
>> Not investigating the .t itself any further. -Ravi
>> ___ Gluster-devel mailing
>> list Gluster-devel@gluster.org http://lists.gluster.org/mailm
>> an/listinfo/gluster-devel
>
> --
> Pranith
>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Change in rebalance graph

[Pranith Kumar Karampuri]

AFR had similar problem 2 years back and we started persisting afr children
and graph always gets generated with what the xattrs will be in that order
as an option. You can check afr_pending_xattrs_init() for it. On the
glusterd side we give an identifer for each of the bricks.

The main reason we did this is because we didn't want to change this logic
if new xlators get introduced in between client xlator and afr. What will
you do if you add one more xlator between readdir-ahead and dht in future?

Now that I am seeing this mail and also Facebook guys also expressed that
there should be a way for gluster to identify if it is talking to right
bricks recently when they met us. May be we should let each xlator choose
an identifier for its subvolumes and persist it on the bricks and use that
instead of depending on mgmt to do the right things.

I understand this patch is already solving your problem. I see that it is
merged as well but it is not future proof.


On Wed, May 17, 2017 at 10:03 AM, Raghavendra Gowdappa 
wrote:

> dht: Add readdir-ahead in rebalance graph if parallel-readdir is on
>
> Issue:
> The value of linkto xattr is generally the name of the dht's
> next subvol, this requires that the next subvol of dht is not
> changed for the life time of the volume. But with parallel
> readdir enabled, the readdir-ahead loaded below dht, is optional.
> The linkto xattr for first subvol, when:
> - parallel readdir is enabled : "-readdir-head-0"
> - plain distribute volume : "-client-0"
> - distribute replicate volume : "-afr-0"
>
> The value of linkto xattr is "-readdir-head-0" when
> parallel readdir is enabled, and is "-client-0" if
> its disabled. But the dht_lookup takes care of healing if it
> cannot identify which linkto subvol, the xattr points to.
>
> In dht_lookup_cbk, if linkto xattr is found to be "-client-0"
> and parallel readdir is enabled, then it cannot understand the
> value "-client-0" as it expects "-readdir-head-0".
> In that case, dht_lookup_everywhere is issued and then the linkto file
> is unlinked and recreated with the right linkto xattr. The issue is
> when parallel readdir is enabled, mount point accesses the file
> that is currently being migrated. Since rebalance process doesn't
> have parallel-readdir feature, it expects "-client-0"
> where as mount expects "-readdir-head-0". Thus at some point
> either the mount or rebalance will fail.
>
> Solution:
> Enable parallel-readdir for rebalance as well and then do not
> allow enabling/disabling parallel-readdir if rebalance is in
> progress.
>
> Change-Id: I241ab966bdd850e667f7768840540546f5289483
> BUG: 1436090
> Signed-off-by: Poornima G 
> Reviewed-on: https://review.gluster.org/17056
> Smoke: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> CentOS-regression: Gluster Build System 
>
>
> Patch: https://review.gluster.org/17056
> owners: Me and Poornima
>
> PS: readdir-ahead is loaded in rebalance graph on top of each subvolume of
> DHT.
>
> regards,
> Raghavendra
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] tests/basic/afr/gfid-mismatch-resolution-with-fav-child-policy.t - regression failures

[Pranith Kumar Karampuri]

karthik, Ravi,
 What is the plan to bring it back? Did you guys find RC for the
failure?

On Mon, May 15, 2017 at 10:52 AM, Ravishankar N 
wrote:

> On 05/12/2017 03:33 PM, Atin Mukherjee wrote:
>
> tests/basic/afr/add-brick-self-heal.t
> 
> is the 2nd in the list.
>
>
> All failures (https://fstat.gluster.org/weeks/1/failure/2) are in netbsd
> and looks like an issue with the slaves.
> Most of the runs have this error:
>
> [07:29:32] Running tests in file ./tests/basic/afr/add-brick-self-heal.t
> volume create: patchy: failed: Host nbslave70.cloud.gluster.org is not in 
> 'Peer in Cluster' state
>
>
> Not investigating the .t itself any further.
>
> -Ravi
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Questions on github

[Pranith Kumar Karampuri]

On Tue, May 9, 2017 at 4:43 PM, Shyam <srang...@redhat.com> wrote:

> Hi,
>
> I would first like to see the habit of developers filing github issues for
> features that they are working on and are also thinking about in the near
> future.
>
> When we have that practice in place, taking it forward for bugs, and
> questions would work better.
>
> Currently we are still on the gaining mindshare for the former. If, as
> maintainers, we can do this better, taking up the latter is easier.
>

Hmm... based on experience, even when quite a few maintainers are there on
gluster-users/gluster-devel, quite a few times the questions pertaining to
a component won't get answered may be because they are busy with something
else. It is a bit cumbersome to find out what are the questions that still
need to be answered with the existing model.

So at least for questions it seems like a good idea to participate on
github, so that if a question doesn't get answered we would at least know
at some point and answer it.


> Shyam
>
> On 05/09/2017 05:27 AM, Pranith Kumar Karampuri wrote:
>
>> hi,
>> Wanted to know what people feel about asking/answering questions on
>> github.com <http://github.com>, at the moment we are only using github
>> for RFEs, I am wondering if it would be fine to open it for questions
>> too. Main benefit I see is that it is easier to see open-questions at a
>> glance and easy to direct someone to the question/answer in future. It
>> is a bit cumbersome to browse through the thread on mailing list
>> compared to github IMHO.
>>
>> --
>> Pranith
>>
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Questions on github

[Pranith Kumar Karampuri]

On Tue, May 9, 2017 at 7:09 PM, Sankarshan Mukhopadhyay <
sankarshan.mukhopadh...@gmail.com> wrote:

> On Tue, May 9, 2017 at 3:18 PM, Amar Tumballi  wrote:
> > I personally prefer github questions than mailing list, because a valid
> > question can later become a reason for a new feature. Also, as you said,
> we
> > can 'assignee' a question and if we start with bug triage we can also
> make
> > sure at least we respond to questions which is pending.
>
> Is the on-going discussion in this thread about using
>  as a method to have
> questions and responses from the community?
>

yeah, this is something users have started doing. It seems better than mail
(at least to me).


>
>
>
> --
> sankarshan mukhopadhyay
> 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Questions on github

[Pranith Kumar Karampuri]

On Tue, May 9, 2017 at 7:27 PM, Sankarshan Mukhopadhyay <
sankarshan.mukhopadh...@gmail.com> wrote:

> On Tue, May 9, 2017 at 7:21 PM, Pranith Kumar Karampuri
> <pkara...@redhat.com> wrote:
> >
> >
> > On Tue, May 9, 2017 at 7:09 PM, Sankarshan Mukhopadhyay
> > <sankarshan.mukhopadh...@gmail.com> wrote:
> >>
> >> On Tue, May 9, 2017 at 3:18 PM, Amar Tumballi <atumb...@redhat.com>
> wrote:
> >> > I personally prefer github questions than mailing list, because a
> valid
> >> > question can later become a reason for a new feature. Also, as you
> said,
> >> > we
> >> > can 'assignee' a question and if we start with bug triage we can also
> >> > make
> >> > sure at least we respond to questions which is pending.
> >>
> >> Is the on-going discussion in this thread about using
> >> <https://github.com/gluster/glusterfs/issues> as a method to have
> >> questions and responses from the community?
> >
> >
> > yeah, this is something users have started doing. It seems better than
> mail
> > (at least to me).
> >
>
> There is a trend of projects who are moving to Github Issues as a
> medium/platform for responding to queries. As Amar mentions earlier in
> the thread and Shyam implies - this requires constant (ie. daily)
> vigil and attention. If those are in place, it is a practical move.
>

People who respond on gluster-users do this already. Github issues is a
better tool to do this (Again IMHO). It is a bit easier to know what
questions are still open to be answered with github. Even after multiple
responses on gluster-users mail you won't be sure if it is answered or not,
so one has to go through the responses. Where as on github we can close it
once answered. So these kinds of things are the reason for asking this.

Shyam,
  I started being more active on github because of the user questions.
So may be different people take different paths to be more active on
github.com/gluster. Some people may not be as active on github even after
we wait for a long time just like in gluster-users so may be we should
start using it for questions sooner? Thoughts? It will only encourage more
developers to be active on github.

___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Questions on github

[Pranith Kumar Karampuri]

On Tue, May 9, 2017 at 9:01 PM, Sankarshan Mukhopadhyay <
sankarshan.mukhopadh...@gmail.com> wrote:

> On Tue, May 9, 2017 at 8:50 PM, Niels de Vos  wrote:
>
> [much snipping]
>
> > A but related to this, but is Stack Overflow not *the* place to ask and
> > answer questions? There even is a "glusterfs" tag, and questions and
> > answers can be marked even better than with GitHub (imho):
> >
> > https://stackoverflow.com/questions/tagged/glusterfs
> >
>
> Alright. The intended outcome (from how I comprehend this conversation
> thread) is that developers/maintainers desire to respond more
> (quickly/efficiently) to queries from users in the community. The way
> this outcome is achieved is when the
> developers/maintainers/those-who-know respond more often. The tooling
> or, medium is not what is the crucial part here. However, it becomes
> critical when there are far too many of avenues and too little
> attention on a regular basis. *That* is a far from ideal situation.
>

Yeah, if maintainers are expected to be active on github, then answering
questions which are right there is just a step away.


>
> --
> sankarshan mukhopadhyay
> 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Qusetions] About the implemention of function gf_backtrace_fillframes

[Pranith Kumar Karampuri]

This is the patch which introduced this change, seems like the author
wanted it work under memory pressure. I didn't read it carefully though.

glusterd: Add last successful glusterd lock backtrace

Also, moved the backtrace fetching logic to a separate function.
Modified the backtrace fetching logic able to work under memory pressure
conditions.

Change-Id: Ie38bea425a085770f41831314aeda95595177ece
BUG: 1138503
Signed-off-by: Krishnan Parthasarathi 
Reviewed-on: http://review.gluster.org/8584
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy 
Reviewed-by: Atin Mukherjee 


On Tue, Jun 20, 2017 at 8:38 AM, C0reFast  wrote:

> When I trying to listing /tmp in a gluster server. I found that have some
> bt prefix files like:
> [root@xxx# ll /tmp/
> ls: cannot access /tmp/btm1RpMm: No such file or directory
> total 116
> -rw---  1 root root   129 Jan 13 17:11 bt0tJH3c
> -?? ? ???? btm1RpMm
> -rw---  1 root root   287 Jan 13 17:11 btyDGNO9
> drwx--. 2 root root 16384 Oct 19 09:21 lost+found
>
> so i checked the source code. found in libglusterfs/src/common-utils.c
>
> in function gf_backtrace_fillframes:
>
> 1. call frames = backtrace (array, GF_BACKTRACE_FRAME_COUNT); to get
> backtrace.
> 2. save backtrace to a temp file.
> 3. read backtrace from temp file to btbuf.
>
> so why need writing a temp file instead just doing this in memory?
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] about deduplication feature

[Pranith Kumar Karampuri]

On Tue, Jun 20, 2017 at 7:29 AM, Li, Dan  wrote:

> Hi, all
>
> we are using GlusterFS to construct our distribute filesystem.
> Does gulsterFS has the deduplication feature on volumes?
>
Will you support it in the future?
>

hi Lidan,
  At the moment, GlusterFS doesn't have any deduplication feature.
There were plans to do it sometime back with reflinks but nothing concrete
happened. So we don't know if it will be supported in future or not. Some
people use other software at different layers underneath to achieve this.


> Thanks,
>
> Lidan
>
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] geo-rep regression because of node-uuid change

[Pranith Kumar Karampuri]

On Wed, Jun 21, 2017 at 10:07 AM, Nithya Balachandran <nbala...@redhat.com>
wrote:

>
> On 20 June 2017 at 20:38, Aravinda <avish...@redhat.com> wrote:
>
>> On 06/20/2017 06:02 PM, Pranith Kumar Karampuri wrote:
>>
>> Xavi, Aravinda and I had a discussion on #gluster-dev and we agreed to go
>> with the format Aravinda suggested for now and in future we wanted some
>> more changes for dht to detect which subvolume went down came back up, at
>> that time we will revisit the solution suggested by Xavi.
>>
>> Susanth is doing the dht changes
>> Aravinda is doing geo-rep changes
>>
>> Done. Geo-rep patch sent for review https://review.gluster.org/17582
>>
>>
> The proposed changes to the node-uuid behaviour (while good) are going to
> break tiering . Tiering changes will take a little more time to be coded
> and tested.
>
> As this is a regression for 3.11 and a blocker for 3.11.1, I suggest we go
> back to the original node-uuid behaviour for now so as to unblock the
> release and target the proposed changes for the next 3.11 releases.
>

Let me see if I understand the changes correctly. We are restoring the
behavior of node-uuid xattr and adding a new xattr for parallel rebalance
for both afr and ec, correct? Otherwise that is one more regression. If
yes, we will also wait for Xavi's inputs. Jeff accidentally merged the afr
patch yesterday which does these changes. If everyone is in agreement, we
will leave it as is and add similar changes in ec as well. If we are not in
agreement, then we will let the discussion progress :-)


>
>
> Regards,
> Nithya
>
>> --
>> Aravinda
>>
>>
>>
>> Thanks to all of you guys for the discussions!
>>
>> On Tue, Jun 20, 2017 at 5:05 PM, Xavier Hernandez <xhernan...@datalab.es>
>> wrote:
>>
>>> Hi Aravinda,
>>>
>>> On 20/06/17 12:42, Aravinda wrote:
>>>
>>>> I think following format can be easily adopted by all components
>>>>
>>>> UUIDs of a subvolume are seperated by space and subvolumes are separated
>>>> by comma
>>>>
>>>> For example, node1 and node2 are replica with U1 and U2 UUIDs
>>>> respectively and
>>>> node3 and node4 are replica with U3 and U4 UUIDs respectively
>>>>
>>>> node-uuid can return "U1 U2,U3 U4"
>>>>
>>>
>>> While this is ok for current implementation, I think this can be
>>> insufficient if there are more layers of xlators that require to indicate
>>> some sort of grouping. Some representation that can represent hierarchy
>>> would be better. For example: "(U1 U2) (U3 U4)" (we can use spaces or comma
>>> as a separator).
>>>
>>>
>>>> Geo-rep can split by "," and then split by space and take first UUID
>>>> DHT can split the value by space or comma and get unique UUIDs list
>>>>
>>>
>>> This doesn't solve the problem I described in the previous email. Some
>>> more logic will need to be added to avoid more than one node from each
>>> replica-set to be active. If we have some explicit hierarchy information in
>>> the node-uuid value, more decisions can be taken.
>>>
>>> An initial proposal I made was this:
>>>
>>> DHT[2](AFR[2,0](NODE(U1), NODE(U2)), AFR[2,0](NODE(U1), NODE(U2)))
>>>
>>> This is harder to parse, but gives a lot of information: DHT with 2
>>> subvolumes, each subvolume is an AFR with replica 2 and no arbiters. It's
>>> also easily extensible with any new xlator that changes the layout.
>>>
>>> However maybe this is not the moment to do this, and probably we could
>>> implement this in a new xattr with a better name.
>>>
>>> Xavi
>>>
>>>
>>>
>>>> Another question is about the behavior when a node is down, existing
>>>> node-uuid xattr will not return that UUID if a node is down. What is the
>>>> behavior with the proposed xattr?
>>>>
>>>> Let me know your thoughts.
>>>>
>>>> regards
>>>> Aravinda VK
>>>>
>>>> On 06/20/2017 03:06 PM, Aravinda wrote:
>>>>
>>>>> Hi Xavi,
>>>>>
>>>>> On 06/20/2017 02:51 PM, Xavier Hernandez wrote:
>>>>>
>>>>>> Hi Aravinda,
>>>>>>
>>>>>> On 20/06/17 11:05, Pranith Kumar Karampuri wrote:
>>>>>>
>>>>>>> Adding more people to get a consensus about th

Re: [Gluster-devel] geo-rep regression because of node-uuid change

[Pranith Kumar Karampuri]

On Wed, Jun 21, 2017 at 1:00 PM, Xavier Hernandez <xhernan...@datalab.es>
wrote:

> I'm ok with reverting node-uuid content to the previous format and create
> a new xattr for the new format. Currently, only rebalance will use it.
>
> Only thing to consider is what can happen if we have a half upgraded
> cluster where some clients have this change and some not. Can rebalance
> work in this situation ? if so, could there be any issue ?
>

I think there shouldn't be any problem, because this is in-memory xattr so
layers below afr/ec will only see node-uuid xattr.
This also gives us a chance to do whatever we want to do in future with
this xattr without any problems about backward compatibility.

You can check
https://review.gluster.org/#/c/17576/3/xlators/cluster/afr/src/afr-inode-read.c@1507
for how karthik implemented this in AFR (this got merged accidentally
yesterday, but looks like this is what we are settling on)


>
> Xavi
>
>
> On Wednesday, June 21, 2017 06:56 CEST, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>
>
>
> On Wed, Jun 21, 2017 at 10:07 AM, Nithya Balachandran <nbala...@redhat.com
> > wrote:
>>
>>
>> On 20 June 2017 at 20:38, Aravinda <avish...@redhat.com> wrote:
>>>
>>> On 06/20/2017 06:02 PM, Pranith Kumar Karampuri wrote:
>>>
>>> Xavi, Aravinda and I had a discussion on #gluster-dev and we agreed to
>>> go with the format Aravinda suggested for now and in future we wanted some
>>> more changes for dht to detect which subvolume went down came back up, at
>>> that time we will revisit the solution suggested by Xavi.
>>>
>>> Susanth is doing the dht changes
>>> Aravinda is doing geo-rep changes
>>>
>>> Done. Geo-rep patch sent for review https://review.gluster.org/17582
>>>
>>>
>>
>> The proposed changes to the node-uuid behaviour (while good) are going to
>> break tiering . Tiering changes will take a little more time to be coded
>> and tested.
>>
>> As this is a regression for 3.11 and a blocker for 3.11.1, I suggest we
>> go back to the original node-uuid behaviour for now so as to unblock the
>> release and target the proposed changes for the next 3.11 releases.
>>
>
> Let me see if I understand the changes correctly. We are restoring the
> behavior of node-uuid xattr and adding a new xattr for parallel rebalance
> for both afr and ec, correct? Otherwise that is one more regression. If
> yes, we will also wait for Xavi's inputs. Jeff accidentally merged the afr
> patch yesterday which does these changes. If everyone is in agreement, we
> will leave it as is and add similar changes in ec as well. If we are not in
> agreement, then we will let the discussion progress :-)
>
>
>>
>>
>> Regards,
>> Nithya
>>
>>> --
>>> Aravinda
>>>
>>>
>>>
>>> Thanks to all of you guys for the discussions!
>>>
>>> On Tue, Jun 20, 2017 at 5:05 PM, Xavier Hernandez <xhernan...@datalab.es
>>> > wrote:
>>>>
>>>> Hi Aravinda,
>>>>
>>>> On 20/06/17 12:42, Aravinda wrote:
>>>>>
>>>>> I think following format can be easily adopted by all components
>>>>>
>>>>> UUIDs of a subvolume are seperated by space and subvolumes are
>>>>> separated
>>>>> by comma
>>>>>
>>>>> For example, node1 and node2 are replica with U1 and U2 UUIDs
>>>>> respectively and
>>>>> node3 and node4 are replica with U3 and U4 UUIDs respectively
>>>>>
>>>>> node-uuid can return "U1 U2,U3 U4"
>>>>
>>>>
>>>> While this is ok for current implementation, I think this can be
>>>> insufficient if there are more layers of xlators that require to indicate
>>>> some sort of grouping. Some representation that can represent hierarchy
>>>> would be better. For example: "(U1 U2) (U3 U4)" (we can use spaces or comma
>>>> as a separator).
>>>>
>>>>>
>>>>>
>>>>> Geo-rep can split by "," and then split by space and take first UUID
>>>>> DHT can split the value by space or comma and get unique UUIDs list
>>>>
>>>>
>>>> This doesn't solve the problem I described in the previous email. Some
>>>> more logic will need to be added to avoid more than one node from each
>>>> replica-set to be active. If we have some explicit hierarchy information in
>>>> the n

Re: [Gluster-devel] geo-rep regression because of node-uuid change

[Pranith Kumar Karampuri]

Adding more people to get a consensus about this.

On Tue, Jun 20, 2017 at 1:49 PM, Aravinda <avish...@redhat.com> wrote:

>
> regards
> Aravinda VK
>
>
> On 06/20/2017 01:26 PM, Xavier Hernandez wrote:
>
>> Hi Pranith,
>>
>> adding gluster-devel, Kotresh and Aravinda,
>>
>> On 20/06/17 09:45, Pranith Kumar Karampuri wrote:
>>
>>>
>>>
>>> On Tue, Jun 20, 2017 at 1:12 PM, Xavier Hernandez <xhernan...@datalab.es
>>> <mailto:xhernan...@datalab.es>> wrote:
>>>
>>> On 20/06/17 09:31, Pranith Kumar Karampuri wrote:
>>>
>>> The way geo-replication works is:
>>> On each machine, it does getxattr of node-uuid and check if its
>>> own uuid
>>> is present in the list. If it is present then it will consider
>>> it active
>>> otherwise it will be considered passive. With this change we are
>>> giving
>>> all uuids instead of first-up subvolume. So all machines think
>>> they are
>>> ACTIVE which is bad apparently. So that is the reason. Even I
>>> felt bad
>>> that we are doing this change.
>>>
>>>
>>> And what about changing the content of node-uuid to include some
>>> sort of hierarchy ?
>>>
>>> for example:
>>>
>>> a single brick:
>>>
>>> NODE()
>>>
>>> AFR/EC:
>>>
>>> AFR[2](NODE(), NODE())
>>> EC[3,1](NODE(), NODE(), NODE())
>>>
>>> DHT:
>>>
>>> DHT[2](AFR[2](NODE(), NODE()), AFR[2](NODE(),
>>> NODE()))
>>>
>>> This gives a lot of information that can be used to take the
>>> appropriate decisions.
>>>
>>>
>>> I guess that is not backward compatible. Shall I CC gluster-devel and
>>> Kotresh/Aravinda?
>>>
>>
>> Is the change we did backward compatible ? if we only require the first
>> field to be a GUID to support backward compatibility, we can use something
>> like this:
>>
> No. But the necessary change can be made to Geo-rep code as well if format
> is changed, Since all these are built/shipped together.
>
> Geo-rep uses node-id as follows,
>
> list = listxattr(node-uuid)
> active_node_uuids = list.split(SPACE)
> active_node_flag = True if self.node_id exists in active_node_uuids else
> False
>
>
>
>> Bricks:
>>
>> 
>>
>> AFR/EC:
>> (, )
>>
>> DHT:
>> ((, ...), (, ...))
>>
>> In this case, AFR and EC would return the same  they returned
>> before the patch, but between '(' and ')' they put the full list of guid's
>> of all nodes. The first  can be used by geo-replication. The list
>> after the first  can be used for rebalance.
>>
>> Not sure if there's any user of node-uuid above DHT.
>>
>> Xavi
>>
>>
>>>
>>>
>>> Xavi
>>>
>>>
>>> On Tue, Jun 20, 2017 at 12:46 PM, Xavier Hernandez
>>> <xhernan...@datalab.es <mailto:xhernan...@datalab.es>
>>> <mailto:xhernan...@datalab.es <mailto:xhernan...@datalab.es>>>
>>> wrote:
>>>
>>> Hi Pranith,
>>>
>>> On 20/06/17 07:53, Pranith Kumar Karampuri wrote:
>>>
>>> hi Xavi,
>>>We all made the mistake of not sending about
>>> changing
>>> behavior of
>>> node-uuid xattr so that rebalance can use multiple nodes
>>> for doing
>>> rebalance. Because of this on geo-rep all the workers
>>> are becoming
>>> active instead of one per EC/AFR subvolume. So we are
>>> frantically trying
>>> to restore the functionality of node-uuid and introduce
>>> a new
>>> xattr for
>>> the new behavior. Sunil will be sending out a patch for
>>> this.
>>>
>>>
>>> Wouldn't it be better to change geo-rep behavior to use the
>>> new data
>>> ? I think it's better as it's now, since it gives more
>>> information
>>> to upper layers so that they can take more accurate
>>> decisions.
>>>
>>> Xavi
>>>
>>>
>>> --
>>> Pranith
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Pranith
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Pranith
>>>
>>
>>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release 3.11.1: Scheduled for 20th of June

[Pranith Kumar Karampuri]

On Tue, Jun 6, 2017 at 6:54 PM, Shyam  wrote:

> Hi,
>
> It's time to prepare the 3.11.1 release, which falls on the 20th of
> each month [4], and hence would be June-20th-2017 this time around.
>
> This mail is to call out the following,
>
> 1) Are there any pending *blocker* bugs that need to be tracked for
> 3.11.1? If so mark them against the provided tracker [1] as blockers
> for the release, or at the very least post them as a response to this
> mail
>

I added https://bugzilla.redhat.com/show_bug.cgi?id=1463250 as blocker just
now for this release. We just completed the discussion about solution on
gluster-devel. We are hoping to get the patch in by EOD tomorrow IST. This
is a geo-rep regression we introduced because of changing node-uuid
behavior. My mistake :-(


>
> 2) Pending reviews in the 3.11 dashboard will be part of the release,
> *iff* they pass regressions and have the review votes, so use the
> dashboard [2] to check on the status of your patches to 3.11 and get
> these going
>
> 3) Empty release notes are posted here [3], if there are any specific
> call outs for 3.11 beyond bugs, please update the review, or leave a
> comment in the review, for us to pick it up
>
> Thanks,
> Shyam/Kaushal
>
> [1] Release bug tracker: https://bugzilla.redhat.com/sh
> ow_bug.cgi?id=glusterfs-3.11.1
>
> [2] 3.11 review dashboard: https://review.gluster.org/#/p
> rojects/glusterfs,dashboards/dashboard:3-11-dashboard
>
> [3] Release notes WIP: https://review.gluster.org/17480
>
> [4] Release calendar: https://www.gluster.org/community/release-schedule/
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] geo-rep regression because of node-uuid change

[Pranith Kumar Karampuri]

Xavi, Aravinda and I had a discussion on #gluster-dev and we agreed to go
with the format Aravinda suggested for now and in future we wanted some
more changes for dht to detect which subvolume went down came back up, at
that time we will revisit the solution suggested by Xavi.

Susanth is doing the dht changes
Aravinda is doing geo-rep changes

Thanks to all of you guys for the discussions!

On Tue, Jun 20, 2017 at 5:05 PM, Xavier Hernandez <xhernan...@datalab.es>
wrote:

> Hi Aravinda,
>
> On 20/06/17 12:42, Aravinda wrote:
>
>> I think following format can be easily adopted by all components
>>
>> UUIDs of a subvolume are seperated by space and subvolumes are separated
>> by comma
>>
>> For example, node1 and node2 are replica with U1 and U2 UUIDs
>> respectively and
>> node3 and node4 are replica with U3 and U4 UUIDs respectively
>>
>> node-uuid can return "U1 U2,U3 U4"
>>
>
> While this is ok for current implementation, I think this can be
> insufficient if there are more layers of xlators that require to indicate
> some sort of grouping. Some representation that can represent hierarchy
> would be better. For example: "(U1 U2) (U3 U4)" (we can use spaces or comma
> as a separator).
>
>
>> Geo-rep can split by "," and then split by space and take first UUID
>> DHT can split the value by space or comma and get unique UUIDs list
>>
>
> This doesn't solve the problem I described in the previous email. Some
> more logic will need to be added to avoid more than one node from each
> replica-set to be active. If we have some explicit hierarchy information in
> the node-uuid value, more decisions can be taken.
>
> An initial proposal I made was this:
>
> DHT[2](AFR[2,0](NODE(U1), NODE(U2)), AFR[2,0](NODE(U1), NODE(U2)))
>
> This is harder to parse, but gives a lot of information: DHT with 2
> subvolumes, each subvolume is an AFR with replica 2 and no arbiters. It's
> also easily extensible with any new xlator that changes the layout.
>
> However maybe this is not the moment to do this, and probably we could
> implement this in a new xattr with a better name.
>
> Xavi
>
>
>
>> Another question is about the behavior when a node is down, existing
>> node-uuid xattr will not return that UUID if a node is down. What is the
>> behavior with the proposed xattr?
>>
>> Let me know your thoughts.
>>
>> regards
>> Aravinda VK
>>
>> On 06/20/2017 03:06 PM, Aravinda wrote:
>>
>>> Hi Xavi,
>>>
>>> On 06/20/2017 02:51 PM, Xavier Hernandez wrote:
>>>
>>>> Hi Aravinda,
>>>>
>>>> On 20/06/17 11:05, Pranith Kumar Karampuri wrote:
>>>>
>>>>> Adding more people to get a consensus about this.
>>>>>
>>>>> On Tue, Jun 20, 2017 at 1:49 PM, Aravinda <avish...@redhat.com
>>>>> <mailto:avish...@redhat.com>> wrote:
>>>>>
>>>>>
>>>>> regards
>>>>> Aravinda VK
>>>>>
>>>>>
>>>>> On 06/20/2017 01:26 PM, Xavier Hernandez wrote:
>>>>>
>>>>> Hi Pranith,
>>>>>
>>>>> adding gluster-devel, Kotresh and Aravinda,
>>>>>
>>>>> On 20/06/17 09:45, Pranith Kumar Karampuri wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 20, 2017 at 1:12 PM, Xavier Hernandez
>>>>> <xhernan...@datalab.es <mailto:xhernan...@datalab.es>
>>>>> <mailto:xhernan...@datalab.es
>>>>> <mailto:xhernan...@datalab.es>>> wrote:
>>>>>
>>>>> On 20/06/17 09:31, Pranith Kumar Karampuri wrote:
>>>>>
>>>>> The way geo-replication works is:
>>>>> On each machine, it does getxattr of node-uuid and
>>>>> check if its
>>>>> own uuid
>>>>> is present in the list. If it is present then it
>>>>> will consider
>>>>> it active
>>>>> otherwise it will be considered passive. With this
>>>>> change we are
>>>>> giving
>>>>> all uuids instead of first-up subvolume. So all
>>>>> machines think
>>>>>

Re: [Gluster-devel] [Gluster-Maintainers] Release 3.11.1: Scheduled for 20th of June

[Pranith Kumar Karampuri]

On Tue, Jun 20, 2017 at 7:37 PM, Shyam  wrote:

> Hi,
>
> Release tagging has been postponed by a day to accommodate a fix for a
> regression that has been introduced between 3.11.0 and 3.11.1 (see [1] for
> details).
>
> As a result 3.11.1 will be tagged on the 21st June as of now (further
> delays will be notified to the lists appropriately).
>

The required patches landed upstream for review and are undergoing review.
Could we do the tagging tomorrow? We don't want to rush the patches to make
sure we don't introduce any new bugs at this time.


>
> Thanks,
> Shyam
>
> [1] Bug awaiting fix: https://bugzilla.redhat.com/show_bug.cgi?id=1463250
>
> "Releases are made better together"
>
> On 06/06/2017 09:24 AM, Shyam wrote:
>
>> Hi,
>>
>> It's time to prepare the 3.11.1 release, which falls on the 20th of
>> each month [4], and hence would be June-20th-2017 this time around.
>>
>> This mail is to call out the following,
>>
>> 1) Are there any pending *blocker* bugs that need to be tracked for
>> 3.11.1? If so mark them against the provided tracker [1] as blockers
>> for the release, or at the very least post them as a response to this
>> mail
>>
>> 2) Pending reviews in the 3.11 dashboard will be part of the release,
>> *iff* they pass regressions and have the review votes, so use the
>> dashboard [2] to check on the status of your patches to 3.11 and get
>> these going
>>
>> 3) Empty release notes are posted here [3], if there are any specific
>> call outs for 3.11 beyond bugs, please update the review, or leave a
>> comment in the review, for us to pick it up
>>
>> Thanks,
>> Shyam/Kaushal
>>
>> [1] Release bug tracker:
>> https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.11.1
>>
>> [2] 3.11 review dashboard:
>> https://review.gluster.org/#/projects/glusterfs,dashboards/d
>> ashboard:3-11-dashboard
>>
>>
>> [3] Release notes WIP: https://review.gluster.org/17480
>>
>> [4] Release calendar: https://www.gluster.org/community/release-schedule/
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release 3.11.1: Scheduled for 20th of June

[Pranith Kumar Karampuri]

On Wed, Jun 21, 2017 at 9:12 PM, Shyam <srang...@redhat.com> wrote:

> On 06/21/2017 11:37 AM, Pranith Kumar Karampuri wrote:
>
>>
>>
>> On Tue, Jun 20, 2017 at 7:37 PM, Shyam <srang...@redhat.com
>> <mailto:srang...@redhat.com>> wrote:
>>
>> Hi,
>>
>> Release tagging has been postponed by a day to accommodate a fix for
>> a regression that has been introduced between 3.11.0 and 3.11.1 (see
>> [1] for details).
>>
>> As a result 3.11.1 will be tagged on the 21st June as of now
>> (further delays will be notified to the lists appropriately).
>>
>>
>> The required patches landed upstream for review and are undergoing
>> review. Could we do the tagging tomorrow? We don't want to rush the
>> patches to make sure we don't introduce any new bugs at this time.
>>
>
> Agreed, considering the situation we would be tagging the release tomorrow
> (June-22nd 2017).
>

Status of afr/ec patches:

EC patch on master: https://review.gluster.org/17594
EC patch on release-3.11: https://review.gluster.org/17615

Master patch is already merged, and 3.11 patch:
https://review.gluster.org/17602

DHT patch: https://review.gluster.org/17595, I guess this patch needs
review as well as regression results.

At the moment we are awaiting regression results of all these patches.


>
>
>>
>>
>> Thanks,
>> Shyam
>>
>> [1] Bug awaiting fix:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1463250
>> <https://bugzilla.redhat.com/show_bug.cgi?id=1463250>
>>
>> "Releases are made better together"
>>
>> On 06/06/2017 09:24 AM, Shyam wrote:
>>
>> Hi,
>>
>> It's time to prepare the 3.11.1 release, which falls on the 20th
>> of
>> each month [4], and hence would be June-20th-2017 this time
>> around.
>>
>> This mail is to call out the following,
>>
>> 1) Are there any pending *blocker* bugs that need to be tracked
>> for
>> 3.11.1? If so mark them against the provided tracker [1] as
>> blockers
>> for the release, or at the very least post them as a response to
>> this
>> mail
>>
>> 2) Pending reviews in the 3.11 dashboard will be part of the
>> release,
>> *iff* they pass regressions and have the review votes, so use the
>> dashboard [2] to check on the status of your patches to 3.11 and
>> get
>> these going
>>
>> 3) Empty release notes are posted here [3], if there are any
>> specific
>> call outs for 3.11 beyond bugs, please update the review, or
>> leave a
>> comment in the review, for us to pick it up
>>
>> Thanks,
>> Shyam/Kaushal
>>
>> [1] Release bug tracker:
>> https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.11.1
>> <https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.11.1>
>>
>> [2] 3.11 review dashboard:
>> https://review.gluster.org/#/projects/glusterfs,dashboards/d
>> ashboard:3-11-dashboard
>> <https://review.gluster.org/#/projects/glusterfs,dashboards/
>> dashboard:3-11-dashboard>
>>
>>
>> [3] Release notes WIP: https://review.gluster.org/17480
>> <https://review.gluster.org/17480>
>>
>> [4] Release calendar:
>> https://www.gluster.org/community/release-schedule/
>> <https://www.gluster.org/community/release-schedule/>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org <mailto:Gluster-devel@gluster.org>
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>> <http://lists.gluster.org/mailman/listinfo/gluster-devel>
>>
>> ___
>> maintainers mailing list
>> maintain...@gluster.org <mailto:maintain...@gluster.org>
>> http://lists.gluster.org/mailman/listinfo/maintainers
>> <http://lists.gluster.org/mailman/listinfo/maintainers>
>>
>>
>>
>>
>> --
>> Pranith
>>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] reagarding backport information while porting patches

[Pranith Kumar Karampuri]

hi,
 Now that we are doing backports with same Change-Id, we can find the
patches and their backports both online and in the tree without any extra
information in the commit message. So shall we stop adding text similar to:

> Reviewed-on: https://review.gluster.org/17414
> Smoke: Gluster Build System <jenk...@build.gluster.org>
> Reviewed-by: Pranith Kumar Karampuri <pkara...@redhat.com>
    > Tested-by: Pranith Kumar Karampuri <pkara...@redhat.com>
> NetBSD-regression: NetBSD Build System <jenk...@build.gluster.org>
> Reviewed-by: Amar Tumballi <ama...@redhat.com>
> CentOS-regression: Gluster Build System <jenk...@build.gluster.org>
(cherry picked from commit de92c363c95d16966dbcc9d8763fd4448dd84d13)

in the patches?

Do you see any other value from this information that I might be missing?

-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

[Pranith Kumar Karampuri]

On Fri, Jun 23, 2017 at 9:37 AM, Ravishankar N <ravishan...@redhat.com>
wrote:

> On 06/23/2017 09:15 AM, Pranith Kumar Karampuri wrote:
>
> hi,
>  Now that we are doing backports with same Change-Id, we can find the
> patches and their backports both online and in the tree without any extra
> information in the commit message. So shall we stop adding text similar to:
>
> > Reviewed-on: https://review.gluster.org/17414
>
>
> Sometimes I combine 2 commits from master (typically commit 2 which fixes
> a bug in commit 1) in to a single patch while backporting. The change ID is
> not the same in that case and I explicitly mention the 2 patch urls in the
> squashed commit sent to the release branch.  So in those cases, some way to
> trace back to the patches in master is helpful. Otherwise I think it is
> fair to omit it.
>

Ah! makes sense. Maybe for exceptions, let us use this but as a rule maybe
it doesn't seem like a bad idea to omit. Let us also hear from others.


> > Smoke: Gluster Build System <jenk...@build.gluster.org>
> > Reviewed-by: Pranith Kumar Karampuri <pkara...@redhat.com>
> > Tested-by: Pranith Kumar Karampuri <pkara...@redhat.com>
> > NetBSD-regression: NetBSD Build System <jenk...@build.gluster.org>
> > Reviewed-by: Amar Tumballi <ama...@redhat.com>
> > CentOS-regression: Gluster Build System <jenk...@build.gluster.org>
> (cherry picked from commit de92c363c95d16966dbcc9d8763fd4448dd84d13)
>
> in the patches?
>
> Do you see any other value from this information that I might be missing?
>
> --
> Pranith
>
>
> ___
> Gluster-devel mailing 
> listGluster-devel@gluster.orghttp://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

[Pranith Kumar Karampuri]

On Fri, Jun 23, 2017 at 1:30 PM, Niels de Vos <nde...@redhat.com> wrote:

> On Fri, Jun 23, 2017 at 09:15:21AM +0530, Pranith Kumar Karampuri wrote:
> > hi,
> >  Now that we are doing backports with same Change-Id, we can find the
> > patches and their backports both online and in the tree without any extra
> > information in the commit message. So shall we stop adding text similar
> to:
> >
> > > Reviewed-on: https://review.gluster.org/17414
> > > Smoke: Gluster Build System <jenk...@build.gluster.org>
> > > Reviewed-by: Pranith Kumar Karampuri <pkara...@redhat.com>
> > > Tested-by: Pranith Kumar Karampuri <pkara...@redhat.com>
> > > NetBSD-regression: NetBSD Build System <jenk...@build.gluster.org>
> > > Reviewed-by: Amar Tumballi <ama...@redhat.com>
> > > CentOS-regression: Gluster Build System <jenk...@build.gluster.org
> >
> > (cherry picked from commit de92c363c95d16966dbcc9d8763fd4448dd84d13)
> >
> > in the patches?
> >
> > Do you see any other value from this information that I might be missing?
>
> I think it is good practise to mention where the backport comes from,
> who developed and reviewed the original. At least the commit-id is
> important, that way the backport can easily be compared to the original.
> git does not know about Change-Ids, but does know commmit-ids :)
>

Change-ID captures all this information. You can know the patch in all
branches with Change-ID, now that we are following same Change-ID across
branches.


>
> We should try to have all the needed details in the git repository, and
> not rely on Gerrit for patch verification/checking. When I'm working on
> a patch and wonder why/when something related was changed, I'll use the
> local history, and do not want to depend on Gerrit.
>

Change-ID is mentioned in the commit which is there in the git log, so we
can figure out the information without needing internet/gerrit. So that
part is not a problem.

All of this information was important to mention earlier because there was
no common thing binding all together. With same Change-ID across branches
for a patch, it seems unnecessary to mention this information in the commit
message.


> Thanks,
> Niels
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

[Pranith Kumar Karampuri]

On Fri, Jun 23, 2017 at 4:21 PM, Niels de Vos <nde...@redhat.com> wrote:

> On Fri, Jun 23, 2017 at 03:53:42PM +0530, Pranith Kumar Karampuri wrote:
> > On Fri, Jun 23, 2017 at 3:01 PM, Niels de Vos <nde...@redhat.com> wrote:
> >
> > > On Fri, Jun 23, 2017 at 01:47:57PM +0530, Pranith Kumar Karampuri
> wrote:
> > > > On Fri, Jun 23, 2017 at 1:30 PM, Niels de Vos <nde...@redhat.com>
> wrote:
> > > >
> > > > > On Fri, Jun 23, 2017 at 09:15:21AM +0530, Pranith Kumar Karampuri
> > > wrote:
> > > > > > hi,
> > > > > >  Now that we are doing backports with same Change-Id, we can
> > > find the
> > > > > > patches and their backports both online and in the tree without
> any
> > > extra
> > > > > > information in the commit message. So shall we stop adding text
> > > similar
> > > > > to:
> > > > > >
> > > > > > > Reviewed-on: https://review.gluster.org/17414
> > > > > > > Smoke: Gluster Build System <jenk...@build.gluster.org>
> > > > > > > Reviewed-by: Pranith Kumar Karampuri <pkara...@redhat.com>
> > > > > > > Tested-by: Pranith Kumar Karampuri <pkara...@redhat.com>
> > > > > > > NetBSD-regression: NetBSD Build System <
> > > jenk...@build.gluster.org>
> > > > > > > Reviewed-by: Amar Tumballi <ama...@redhat.com>
> > > > > > > CentOS-regression: Gluster Build System <
> > > jenk...@build.gluster.org
> > > > > >
> > > > > > (cherry picked from commit de92c363c95d16966dbcc9d8763fd4
> > > 448dd84d13)
> > > > > >
> > > > > > in the patches?
> > > > > >
> > > > > > Do you see any other value from this information that I might be
> > > missing?
> > > > >
> > > > > I think it is good practise to mention where the backport comes
> from,
> > > > > who developed and reviewed the original. At least the commit-id is
> > > > > important, that way the backport can easily be compared to the
> > > original.
> > > > > git does not know about Change-Ids, but does know commmit-ids :)
> > > > >
> > > >
> > > > Change-ID captures all this information. You can know the patch in
> all
> > > > branches with Change-ID, now that we are following same Change-ID
> across
> > > > branches.
> > >
> > > However a Change-Id is not standard git, it is purely a Gerrit thing. I
> > > can't cherry-pick or 'git show' a Change-Id, but that works fine with a
> > > git-commit.
> > >
> >
> > Where do we mention git commit-id now? If we do the backport using
> gerrit,
> > it adds it as "(cherry picked from commit
> > de92c363c95d16966dbcc9d8763fd4448dd84d13)",
> > otherwise I don't think it gets mentioned, right?
>
> Correct, that is just what "git cherry-pick -x" does too. It is one of
> the main requirements we check for backports. It is not enforced, but
> strongly encouraged to have it. Nothing in the commit message is
> enforced, it is up to the maintainers to make sure everything makes
> sense there.
>
> Part of this is also mentioned on
> http://gluster.readthedocs.io/en/latest/Developer-guide/
> Backport-Guidelines/
>
> > > I also like to give credits to the people that originally wrote and
> > > reviewed the change. It is not required, but it is nice to have.
> > >
> >
> > If you do the backport using standard commands Author and committer are
> > correctly shown in the patch, I think the tool already handles it. As for
> > the reviewer etc. as this information is available on the actual patches,
> > if the person who is checking for it really wants it, can find out.
>
> Depends, if the patch is not exactly the same, the author should be
> changed to whoever did the backport and add a note explaining the
> difference. Even cherry-picks can be different, and sending those as an
> author who did not do the (incorrect?) work is wrong imho.
>
> But yes, if a backport is straight forward, the original Author of the
> change can surely be kept.
>
>
> Note that all of this is just my opinion, and based on working with many
> different projects that use git (or other tools) to identify patches
> that could be candidates for backporting. In general, the more details
> that are captured 

Re: [Gluster-devel] reagarding backport information while porting patches

[Pranith Kumar Karampuri]

On Fri, Jun 23, 2017 at 7:06 PM, Shyam <srang...@redhat.com> wrote:

> On 06/23/2017 07:00 AM, Pranith Kumar Karampuri wrote:
>
>> Note that all of this is just my opinion, and based on working with
>> many
>> different projects that use git (or other tools) to identify patches
>> that could be candidates for backporting. In general, the more details
>> that are captured in the commit message, the easier it is to get an
>> understanding of the different patches in different branches.
>>
>>
>> Yes, I am also for as much information as possible in the commit with
>> least amount of human effort. In time I would like us to get to a point,
>> where we just have to say: backport release-3.12 release-3.11
>> release-3.10 and the script should clone, send the patches on gerrit and
>> do recheck centos, recheck netbsd, so the only human effort has to be to
>> be merge the patch
>>
>>
> My opinion is that we should retain the information that we currently
> provide, for 2 reasons,
>
> 1) Change-Id is gerrit specific, so if we move away at some later point in
> time, this is not going to help (yes we can search the git log for the same
> change ID etc. but as discussed in this thread, it is not git standard, it
> is gerrit addition)
>

If we move away from gerrit the information we provide now about what is
the patch on master etc are also not of any help.


>
> 2) Using the same Change-Id is not enforced, so till we do that, getting
> to this point is not feasible.
>

This is a valid point I think. But we can provide extra checks in smoke to
check if it is not a backport with correct change-id. So it has solutions


>
> Shyam
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reagarding backport information while porting patches

[Pranith Kumar Karampuri]

On Fri, Jun 23, 2017 at 7:24 PM, Shyam <srang...@redhat.com> wrote:

> On 06/23/2017 09:48 AM, Pranith Kumar Karampuri wrote:
>
>>
>>
>> On Fri, Jun 23, 2017 at 7:06 PM, Shyam <srang...@redhat.com
>> <mailto:srang...@redhat.com>> wrote:
>>
>> On 06/23/2017 07:00 AM, Pranith Kumar Karampuri wrote:
>>
>> Note that all of this is just my opinion, and based on
>> working with many
>> different projects that use git (or other tools) to identify
>> patches
>> that could be candidates for backporting. In general, the
>> more details
>> that are captured in the commit message, the easier it is to
>> get an
>> understanding of the different patches in different branches.
>>
>>
>> Yes, I am also for as much information as possible in the commit
>> with
>> least amount of human effort. In time I would like us to get to
>> a point,
>> where we just have to say: backport release-3.12 release-3.11
>> release-3.10 and the script should clone, send the patches on
>> gerrit and
>> do recheck centos, recheck netbsd, so the only human effort has
>> to be to
>> be merge the patch
>>
>>
>> My opinion is that we should retain the information that we
>> currently provide, for 2 reasons,
>>
>> 1) Change-Id is gerrit specific, so if we move away at some later
>> point in time, this is not going to help (yes we can search the git
>> log for the same change ID etc. but as discussed in this thread, it
>> is not git standard, it is gerrit addition)
>>
>>
>> If we move away from gerrit the information we provide now about what is
>> the patch on master etc are also not of any help.
>>
>
> Yes, but it is better to have this information at present than to drop it
> and loose the practice of providing the information.


If we ensure that the link between different branches is taken care of.
Answer to "Is it better to have this practice of providing information" is
subjective.


> Changing habits are hard, I would rather not change the habit at the
> moment.


I agree. It goes both ways, we will not force a habit on new contributors
who are coming to the community this way. IMHO we can make it easier for
someone to contribute to gluster by reducing manual steps. This is one such
step if we can execute it right handling corner cases.


>
>>
>>
>> 2) Using the same Change-Id is not enforced, so till we do that,
>> getting to this point is not feasible.
>>
>>
>> This is a valid point I think. But we can provide extra checks in smoke
>> to check if it is not a backport with correct change-id. So it has
>> solutions
>>
>
> Yes, this is pending to be done, https://bugzilla.redhat.com/sh
> ow_bug.cgi?id=1428047
>
>
>>
>>
>> Shyam
>>
>>
>>
>>
>> --
>> Pranith
>>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Just a thought, a better way to rebuild replica when some bricks go down rather than replace-brick

[Pranith Kumar Karampuri]

On Thu, May 25, 2017 at 11:35 AM, Jaden Liang  wrote:

> Hi all,
>
> As I know, glusterfs have to replace brick to rebuild replica when some
> bricks go down. In most commercial distributed storage system, there is a
> key spec that indicates how fast to rebuild data when some components
> broke. In glusterfs, the replace-brick operation only use 1 on 1 to rebuild
> replica, this can not  use the cluster disks performance to increase the
> rebuild job that some companies called it RAID2.0. Therefore, I have some
> thoughts what to discuss.
>
> Glusterfs use one single storage graph in a volume, like M x N
> distributed-replicated volume. This storage graph is global for all files
> in the same volume. From what I know in VMWare vSAN, vSAN use different
> graphs for different files, which means, every file has its own storage
> graph. In this case, file replica rebuild or file rebalance could do mush
> flexible than single global graph. If some brick goes down, it can just
> modify those storage graphs of files which lost replica, then rebuild can
> be run which replace-brick operations.
>

This requires architecture change where we know the location of each file
rather than each brick.


>
> Just a thought, any suggestion would be great!
>

There are efforts under way to make self-heal comparable to rsync, would
that help?


>
> Best regards,
> Jaden Liang
> 5/25/2017
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Fwd: Re: GlusterFS removal from Openstack Cinder

[Pranith Kumar Karampuri]

On Wed, May 24, 2017 at 9:10 PM, Joe Julian  wrote:

> Forwarded for posterity and follow-up.
>
>  Forwarded Message 
> Subject: Re: GlusterFS removal from Openstack Cinder
> Date: Fri, 05 May 2017 21:07:27 +
> From: Amye Scavarda  
> To: Eric Harney  , Joe Julian
>  , Vijay Bellur 
> 
> CC: Amye Scavarda  
>
> Eric,
> I'm sorry to hear this.
> I'm reaching out internally (within Gluster CI team and CentOS CI which
> supports Gluster) to get an idea of the level of effort we'll need to
> provide to resolve this.
> It'll take me a few days to get this, but this is on my radar. In the
> meantime, is there somewhere I should be looking at for requirements to
> meet this gateway?
>
> Thanks!
> -- amye
>
> On Fri, May 5, 2017 at 16:09 Joe Julian  wrote:
>
>> On 05/05/2017 12:54 PM, Eric Harney wrote:
>> >> On 04/28/2017 12:41 PM, Joe Julian wrote:
>> >>> I learned, today, that GlusterFS was deprecated and removed from
>> >>> Cinder as one of our #gluster (freenode) users was attempting to
>> >>> upgrade openstack. I could find no rational nor discussion of that
>> >>> removal. Could you please educate me about that decision?
>> >>>
>> >
>> > Hi Joe,
>> >
>> > I can fill in on the rationale here.
>> >
>> > Keeping a driver in the Cinder tree requires running a CI platform to
>> > test that driver and report results against all patchsets submitted to
>> > Cinder.  This is a fairly large burden, which we could not meet once the
>> > Gluster Cinder driver was no longer an active development target at Red
>> Hat.
>> >
>> > This was communicated via a warning issued by the driver for anyone
>> > running the OpenStack Newton code, and via the Cinder release notes for
>> > the Ocata release.  (I can see in retrospect that this was probably not
>> > communicated widely enough.)
>> >
>> > I apologize for not reaching out to the Gluster community about this.
>> >
>> > If someone from the Gluster world is interested in bringing this driver
>> > back, I can help coordinate there.  But it will require someone stepping
>> > in in a big way to maintain it.
>> >
>> > Thanks,
>> > Eric
>>
>> Ah, Red Hat's statement that the acquisition of InkTank was not an
>> abandonment of Gluster seems rather disingenuous now. I'm disappointed.
>>
>
I am a Red Hat employee working on gluster and I am happy with the kind of
investments the company did in GlusterFS. Still am. It is a pretty good
company and really open. I never had any trouble saying something the
management did is wrong when I strongly felt and they would give a decent
reason for their decision.


>
>> Would you please start a thread on the gluster-users and gluster-devel
>> mailing lists and see if there's anyone willing to take ownership of
>> this. I'm certainly willing to participate as well but my $dayjob has
>> gone more kubernetes than openstack so I have only my limited free time
>> that I can donate.
>>
>
Do we know what would maintaining cinder as active entail? Did Eric get
back to any of you?


> --
> Amye Scavarda | a...@redhat.com | Gluster Community Lead
>
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Release 3.11: Blocker bugs status

[Pranith Kumar Karampuri]

Yes, Sunil also wrote a script which does rebalance with the patch
successfully. I went ahead and closed it as duplicate.

On Fri, May 26, 2017 at 3:04 AM, Shyam  wrote:

> Hi,
>
> All marked blockers against 3.11 have been fixed, except this one,
>
> Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1448307
>
> It looks like commit: https://review.gluster.org/#/c/17369/ actually
> implements the required FOP and thus the bug would eventually be fixed due
> to this.
>
> Hence the question I have to Nithya/Pranith/Sunil is, should we close
> 1448307 as a duplicate of https://bugzilla.redhat.com/sh
> ow_bug.cgi?id=1454686 ?
>
> As this would mean, as of Thursday 5:30 PM Eastern, we have no further
> blockers for this release.
>
> Do let me know as we are in the last 2 days before the release, and I
> would like to ensure that all blockers are addressed.
>
> Thanks,
> Shyam
>
> "Releases are made better together"
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Release 3.11: Release notes updates!!! (1 day remaining)

[Pranith Kumar Karampuri]

On Fri, May 26, 2017 at 2:53 AM, Shyam  wrote:

> Hi,
>
> If your name is on the following list, we need your help in updating the
> release notes and thus closing out the final stages of 3.11 release. Please
> do the needful by end of this week! (which means there is single day
> remaining, unless you intend to do this over the weekend)
>
> @pranith, @spalai, @kotresh, @niels, @poornima, @jiffin, @samikshan, @kaleb
>
> Github issues that need release notes updated are (at the end of each line
> the github issue # is mentioned),
>
> 1) Halo in AFR (@pranith) (#199)
>

Release note: https://review.gluster.org/17396

I will need more time for glusterfs-specs though.


> 2) Rebalance performance improvement (@spalai) (#155)
>
> 3) Distritbute: [RFE] More robust transactions during directory namespace
> operations. (@kotresh) (#191)
>
> 4) bitrot: [RFE] Enable object versioning only if bitrot is enabled.
> (@kotresh) (#188)
>
> 5) New xlator to help developers detecting resource leaks (@niels) (#176)
>
> 6) Serve negative lookups from cache (@poornima) (#82)
>
> 7) get-state CLI needs to provide client and brick capacity related
> information as well (@samikshan) (#158)
>
> 8) SELinux support for Gluster Volumes (@niels @jiffin) (#55)
>
> 9) switch to storhaug for HA for ganesha and samba (@kaleb) (#59)
>
> Sample gerrit links that update the release notes:
>   - https://review.gluster.org/17372
>   - https://review.gluster.org/17390
>
> Thanks,
> Shyam
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Backport for "Add back socket for polling of events immediately..."

[Pranith Kumar Karampuri]

On Mon, May 29, 2017 at 8:46 AM, Raghavendra G 
wrote:

> Replying to all queries here:
>
> * Is it a bug or performance enhancement?
>   Its a performance enhancement. No functionality is broken if this patch
> is not taken in.
>
> * Are there performance numbers to validate the claim?
>   https://bugzilla.redhat.com/show_bug.cgi?id=1358606#c9
>
> * Are there any existing users who need this enhancement?
>   https://bugzilla.redhat.com/show_bug.cgi?id=1358606#c27
>
>   Though not sure what branch Zhang Huan is on. @Zhang your inputs are
> needed here.
>
> * Do I think this patch _should_ go into any of the released branches?
>   Personally, I don't feel strongly either way. I am fine with this patch
> not making into any of released branches. But, I do think there are users
> who are affected with this (Especially EC/Disperse configurations). If they
> want to stick to the released branches, pulling into released branches will
> help them. @Pranith/Xavi, what are your opinions on this?
>

3.11.1 seems like a good idea IMO


>
> regards,
> Raghavendra
>
> On Sun, May 28, 2017 at 6:58 PM, Shyam  wrote:
>
>> On 05/28/2017 09:24 AM, Atin Mukherjee wrote:
>>
>>>
>>>
>>> On Sun, May 28, 2017 at 1:48 PM, Niels de Vos >> > wrote:
>>>
>>> On Fri, May 26, 2017 at 12:25:42PM -0400, Shyam wrote:
>>> > Or this one: https://review.gluster.org/15036 <
>>> https://review.gluster.org/15036>
>>> >
>>> > This is backported to 3.8/10 and 3.11 and considering the size and
>>> impact of
>>> > the change, I wanted to be sure that we are going to accept this
>>> across all
>>> > 3 releases?
>>> >
>>> > @Du, would like your thoughts on this.
>>> >
>>> > @niels, @kaushal, @talur, as release owners, could you weigh in as
>>> well
>>> > please.
>>> >
>>> > I am thinking that we get this into 3.11.1 if there is agreement,
>>> and not in
>>> > 3.11.0 as we are finalizing the release in 3 days, and this change
>>> looks
>>> > big, to get in at this time.
>>>
>>>
>>> Given 3.11 is going to be a new release, I'd recommend to get this fix
>>> in (if we have time). https://review.gluster.org/#/c/17402/ is dependent
>>> on this one.
>>>
>>
>> It is not a fix Atin, it is a more fundamental change to request
>> processing, with 2 days to the release, you want me to merge this?
>>
>> Is there a *bug* that will surface without this change or is it a
>> performance enhancement?
>>
>>
>>> >
>>> > Further the change is actually an enhancement, and provides
>>> performance
>>> > benefits, so it is valid as a change itself, but I feel it is too
>>> late to
>>> > add to the current 3.11 release.
>>>
>>> Indeed, and mostly we do not merge enhancements that are non-trivial
>>> to
>>> stable branches. Each change that we backport introduces the chance
>>> on
>>> regressions for users with their unknown (and possibly awkward)
>>> workloads.
>>>
>>> The patch itself looks ok, but it is difficult to predict how the
>>> change
>>> affects current deployments. I prefer to be conservative and not have
>>> this merged in 3.8, at least for now. Are there any statistics in how
>>> performance is affected with this change? Having features like this
>>> only
>>> in newer versions might also convince users to upgrade sooner, 3.8
>>> will
>>> only be supported until 3.12 (or 4.0) gets released, which is
>>> approx. 3
>>> months from now according to our schedule.
>>>
>>> Niels
>>>
>>> ___
>>> maintainers mailing list
>>> maintain...@gluster.org 
>>> http://lists.gluster.org/mailman/listinfo/maintainers
>>> 
>>>
>>>
>>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Raghavendra G
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] threads on client side xlator (EC)

[Pranith Kumar Karampuri]

On Thu, Jun 1, 2017 at 3:18 PM, jayakrishnan mm 
wrote:

> Hi,
> Assuming a client side xlator,(e.g, EC)  how are write requests (to same
> file) from upper layer (DHT)are  handled ? Each time ec_gf_writev()  is
> processed by the same thread ?
>

Not necessarily.
It could be either fuse-thread/epoll-thread and if you use
client-io-threads, it would be one of the io-threads.


>
> Regards
> JK
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Qusetions] How profile affect glusterfs performance?

[Pranith Kumar Karampuri]

On Mon, Jun 5, 2017 at 12:40 PM, Xie Changlong <xiechanglon...@gmail.com>
wrote:

> 在 6/5/2017 2:34 PM, Pranith Kumar Karampuri 写道:
>
>> What is your usecase if I may ask?
>>
>>
> Only fio/iozone now, maybe you can give me better test sugguestion :)
>

I meant what are you using gluster for? VM workload or image/video file
creation or lots of small files etc etc.


>
> seq read
> # dd if=/dev/zero  of=test bs=4k count=524288
> #fio --filename=test -iodepth=64 -ioengine=libaio --direct=1 --rw=read
> --bs=1m --size=2g --numjobs=4 --runtime=10 --group_reporting
> --name=test-read
> seq write
> # fio -filename=test -iodepth=64 -ioengine=libaio -direct=1 -rw=write
> -bs=1m -size=2g -numjobs=4 -runtime=20 -group_reporting -name=test-write
>
> random read
> #fio -filename=test -iodepth=64 -ioengine=libaio -direct=1 -rw=randread
> -bs=4k -size=2G -numjobs=64 -runtime=20 -group_reporting
> -name=test-rand-read
>
> random write
> #fio -filename=test -iodepth=64 -ioengine=libaio -direct=1 -rw=randwrite
> -bs=4k -size=2G -numjobs=64 -runtime=20 -group_reporting
> -name=test-rand-write
>
>
> iozone  1 thread
> # ./iozone -s 10g -r 1m -i 0 -i 1 -f /mnt/test-volume/test -Rb
> /tmp/test_iozone_1.xls
> iozone  2 multi-threads
> # ./iozone -s 10g -r 1m -i 0 -i 1 -f /mnt/test-volume/test -t 8 -Rb
> /tmp/test_iozone_2.xls
>
>
>
> On Mon, Jun 5, 2017 at 11:08 AM, Xie Changlong<xiechanglon...@gmail.com>
>> wrote:
>>
>> 在 6/5/2017 1:22 PM, Pranith Kumar Karampuri 写道:
>>>
>>> On Mon, Jun 5, 2017 at 8:29 AM, Xie Changlong<xiechanglon...@gmail.com>
>>>> wrote:
>>>>
>>>> 在 6/5/2017 10:50 AM, Pranith Kumar Karampuri 写道:
>>>>
>>>>> I think there have been improvements here to use special instructions
>>>>> to
>>>>>
>>>>
> --
> Thanks
> -Xie
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Adding one variable to inode structure

[Pranith Kumar Karampuri]

On Mon, Jun 5, 2017 at 12:40 PM, Tahereh Fattahi <t28.fatt...@gmail.com>
wrote:

> yes you are correct.
> I thought that for creating a video file i first should do a getfattr, if
> it was not set then I should do a setxattr.
> So it would be have bad performance to do a getfattr after every create,
> for video files. Am I correct?
>

How consistent should it be? May be you can do this operation on another
thread or something in the background so that your application may not see
the delay in doing I/O?


>
> On Mon, Jun 5, 2017 at 11:28 AM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>> Oh you want applications to do getfattr to find that it is there?
>>
>> I think I understood what you are looking for now. So basically
>> applications will keep doing creation of some files/directories, whenever a
>> video file is created you want the bricks to set an extended attribute on
>> the directory, so that the application can use it. I don't think this
>> doesn't look like the job of index xlator either.
>>
>> Why do you not want to set the extended attribute from client and want
>> the fs to do it on-behalf of the application? Setting it from client has
>> benefits like even when one brick is down it will automatically heal this
>> extended attribute etc.
>>
>> On Mon, Jun 5, 2017 at 12:10 PM, Tahereh Fattahi <t28.fatt...@gmail.com>
>> wrote:
>>
>>> I want in in mount directory in client side
>>>
>>> On Mon, Jun 5, 2017 at 11:07 AM, Pranith Kumar Karampuri <
>>> pkara...@redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jun 5, 2017 at 11:24 AM, Tahereh Fattahi <t28.fatt...@gmail.com
>>>> > wrote:
>>>>
>>>>> Thank you
>>>>> I see that this xlator is loaded in server side.
>>>>> How can I access to variable in index xlator in client side?
>>>>> is it correct? getfattr trusted.index.myvar
>>>>>
>>>>
>>>> To which xlator do you want this information? Or do you want this on
>>>> mount?
>>>>
>>>>
>>>>>
>>>>> On Mon, Jun 5, 2017 at 10:00 AM, Pranith Kumar Karampuri <
>>>>> pkara...@redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 5, 2017 at 9:55 AM, Tahereh Fattahi <
>>>>>> t28.fatt...@gmail.com> wrote:
>>>>>>
>>>>>>> Assume that one client wants to search it's directories for video
>>>>>>> files.
>>>>>>>  I want use something that helps this client to search just
>>>>>>> directories that have this kind of file.
>>>>>>> like a extended attribute, but I want this attribute be set by
>>>>>>> server not by client.
>>>>>>> I dont know which xlator is suitable for this work.
>>>>>>>
>>>>>>
>>>>>> The xlator that comes close to it is:  index xlator
>>>>>> xlators/features/index/src
>>>>>>
>>>>>> You may have to track extra operations like
>>>>>> create/mknod/link/rename/unlink to make sure you get the
>>>>>> functionality you want. Basically this xlator helps you in indexing a
>>>>>> behavior. We use this for indexing directories/files that need heal etc.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Mon, Jun 5, 2017 at 7:13 AM, Pranith Kumar Karampuri <
>>>>>>> pkara...@redhat.com> wrote:
>>>>>>>
>>>>>>>> This sounds hacky. In general anything that is specific about an
>>>>>>>> inode, we try to store it in inode-ctx. Who uses this information about
>>>>>>>> presence of video-file and how? May be with that knowledge there could 
>>>>>>>> be a
>>>>>>>> possibility we can improve the solution. Do let us know the complete
>>>>>>>> problem you are trying to solve.
>>>>>>>>
>>>>>>>> On Mon, Jun 5, 2017 at 4:53 AM, Tahereh Fattahi <
>>>>>>>> t28.fatt...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>> I want to add one boolean field to inode structure for a directory.
>>>>>>>>>  when it is 1 it means that directory has one or more video file.
>>>>>>>>> when it is 0 it means that there is no video file in that directory.
>>>>>>>>> I can add this variable to inode structure and update it in server
>>>>>>>>> side, in posix_create function (when there is a create request for a 
>>>>>>>>> video
>>>>>>>>> file).
>>>>>>>>> question is about client knowledge about this variable. is it
>>>>>>>>> possible that client can see the amount of this variable of different
>>>>>>>>> servers (bricks) and OR them to one variable in cient's inode of the
>>>>>>>>> directory? in which xlator I should try in client side?
>>>>>>>>>
>>>>>>>>> ___
>>>>>>>>> Gluster-devel mailing list
>>>>>>>>> Gluster-devel@gluster.org
>>>>>>>>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Pranith
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Pranith
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Pranith
>>>>
>>>
>>>
>>
>>
>> --
>> Pranith
>>
>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Qusetions] How profile affect glusterfs performance?

[Pranith Kumar Karampuri]

On Tue, Jun 6, 2017 at 8:14 AM, Xie Changlong <xiechanglon...@gmail.com>
wrote:

> 在 6/5/2017 6:30 PM, Pranith Kumar Karampuri 写道:
>
>> I meant what are you using gluster for? VM workload or image/video file
>> creation or lots of small files etc etc.
>>
>
> 1) We use glusterfs for general purpose, no limit to image/video file
> creation or small files etc.
>
Okay, this is good. What is the cluster size?
Is it replica 3 or replica 2 or arbiter or is it EC volume?

Please don't mind me asking so many details. I am delighted to see you guys
active in the community because I have seen Xiubo Li's work on tcmu-runner
who is also from chinamobile and his work is pretty good :-).


> 2) We just want a low performance affect way to calculate each brick's
> iops/bandwidth for the upper layer management app. BTW, is there any other
> way to get iops/bandwith for each brick besides profile?
>

At the moment we have these stats using profile commands. As per Facebook
patches they enable json capture of io-stats on their volumes and measure
these. They have it enabled always. If that is not enough for you, then we
should probably look at enhancing things. Do send patches if you think
something would make things better :-).


>
> --
> Thanks
> -Xie
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Qusetions] How profile affect glusterfs performance?

[Pranith Kumar Karampuri]

On Wed, Jun 7, 2017 at 2:28 PM, Xie Changlong <xiechanglon...@gmail.com>
wrote:

> 在 6/7/2017 4:47 PM, Pranith Kumar Karampuri 写道:
>
>> Yes, they do. The patches I gave earlier provide the facility to this in
>> io-stats. Do let us know if you have any doubts.
>>
>
> Sorry for slowness, but i think i catch up with U now.
>

Don't worry. Do let us know if you have any doubts, we will be happy to
help.


>
>
>>
>>
> --
> Thanks
> -Xie
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Qusetions] How profile affect glusterfs performance?

[Pranith Kumar Karampuri]

On Wed, Jun 7, 2017 at 1:55 PM, Xie Changlong <xiechanglon...@gmail.com>
wrote:

> 在 6/7/2017 3:08 PM, Pranith Kumar Karampuri 写道:
>
>> On Tue, Jun 6, 2017 at 8:14 AM, Xie Changlong <xiechanglon...@gmail.com>
>> wrote:
>>
>> 在 6/5/2017 6:30 PM, Pranith Kumar Karampuri 写道:
>>>
>>> I meant what are you using gluster for? VM workload or image/video file
>>>> creation or lots of small files etc etc.
>>>>
>>>>
>>> 1) We use glusterfs for general purpose, no limit to image/video file
>>> creation or small files etc.
>>>
>>> Okay, this is good. What is the cluster size?
>> Is it replica 3 or replica 2 or arbiter or is it EC volume?
>>
>
> I use replica 2 on my test.
> But in the real world, "we have deployed more than 100 glusterfs nodes in
> producion(20 nodes for the biggest single cluster)" per Liu Yuan. Replica
> 2/3, or EC are optional.
>
>
>> Please don't mind me asking so many details. I am delighted to see you
>> guys
>>
>
> You are always welcome!
>
> active in the community because I have seen Xiubo Li's work on tcmu-runner
>> who is also from chinamobile and his work is pretty good :-).
>>
>
> Yeah, i would be very pleasant to convey your praise. :)
>
>
>>
>> 2) We just want a low performance affect way to calculate each brick's
>>> iops/bandwidth for the upper layer management app. BTW, is there any
>>> other
>>> way to get iops/bandwith for each brick besides profile?
>>>
>>>
>> At the moment we have these stats using profile commands. As per Facebook
>> patches they enable json capture of io-stats on their volumes and measure
>> these. They have it enabled always. If that is not enough for you, then we
>>
>
> I think you mean FB guys gather data based on io-stats with profile always
> on, am i right?
> BTW, are these patches open to everyone? so i can dig into it.
>

Yes, they do. The patches I gave earlier provide the facility to this in
io-stats. Do let us know if you have any doubts.


>
> should probably look at enhancing things. Do send patches if you think
>> something would make things better :-).
>>
>>
>>
>>> --
>>> Thanks
>>>  -Xie
>>>
>>>
>>
>>
>>
> --
> Thanks
> -Xie
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Qusetions] How profile affect glusterfs performance?

[Pranith Kumar Karampuri]

On Wed, Jun 7, 2017 at 1:14 PM, liuy...@cmss.chinamobile.com <
liuy...@cmss.chinamobile.com> wrote:

> Hi Pranith,
>
> First of all, we owe you guys big thanks for your excellent work.
>
> I'm the lead of storage team in China Mobile, Xiubo is also in my team :)
>

Ah! nice :-).


>
> We have deployed more than 100 glusterfs nodes in producion(20 nodes for
> the biggest single cluster), so far so good.  Use case ranging from
> image/vedio, to small files for mailbox services.
> For profile stuff, we'd like to enable it as always to collect perf stat
> for monitoring.
>

Yes, this is something FB guys do already and contributed the patches back
to community. So you should be able to do this too.


>
> We are planing to provide cloud file service by the combination of
> glusterfs and Openstack Manila this year. The enhancement of manila patches
> would be sent to upsteam later.
>

This is good news.


>
> Also, I have a question for NDMP support. I bumpped one thread discussing
> it but not clear yet. (http://lists.gluster.org/
> pipermail/gluster-devel/2016-August/050513.html)
>
> Do you have any plan to for a glusterfs-ndmp server from scratch? We are
> new to the development of glusterfs, I think ndmp support would be a good
> starting point for us to join the
> development  of the community.  We'd like to see NDMP supported by
> glusterfs because some of our customers want it.
>

I don't know enough about this. Vijay has idea about this, so will respond
later.


>
> Yuan
> --
>
>
> *From:* Pranith Kumar Karampuri <pkara...@redhat.com>
> *Date:* 2017-06-07 15:38
> *To:* Xie Changlong <xiechanglon...@gmail.com>
> *CC:* Gluster Devel <gluster-devel@gluster.org>; Hu Jianfei
> <hujian...@cmss.chinamobile.com>; Liu Yuan <liuy...@cmss.chinamobile.com>
> *Subject:* Re: [Gluster-devel] [Qusetions] How profile affect glusterfs
> performance?
>
>
> On Tue, Jun 6, 2017 at 8:14 AM, Xie Changlong <xiechanglon...@gmail.com>
> wrote:
>
>> 在 6/5/2017 6:30 PM, Pranith Kumar Karampuri 写道:
>>
>>> I meant what are you using gluster for? VM workload or image/video file
>>> creation or lots of small files etc etc.
>>>
>>
>> 1) We use glusterfs for general purpose, no limit to image/video file
>> creation or small files etc.
>>
> Okay, this is good. What is the cluster size?
> Is it replica 3 or replica 2 or arbiter or is it EC volume?
>
> Please don't mind me asking so many details. I am delighted to see you
> guys active in the community because I have seen Xiubo Li's work on
> tcmu-runner who is also from chinamobile and his work is pretty good :-).
>
>
>> 2) We just want a low performance affect way to calculate each brick's
>> iops/bandwidth for the upper layer management app. BTW, is there any other
>> way to get iops/bandwith for each brick besides profile?
>>
>
> At the moment we have these stats using profile commands. As per Facebook
> patches they enable json capture of io-stats on their volumes and measure
> these. They have it enabled always. If that is not enough for you, then we
> should probably look at enhancing things. Do send patches if you think
> something would make things better :-).
>
>
>>
>> --
>> Thanks
>> -Xie
>>
>
>
>
> --
> Pranith
>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Making efficient use of conditional variables

[Pranith Kumar Karampuri]

hi,
I just read the pdf linked in the patch https://review.gluster.org/16832
and learned something I didn't know before about how to use conditional
variables efficiently. Just wanted to share it here in case it is useful
for others too. Do go through the patch as well to see how the idea is used
to reduce contention in io-thread queue.

This is the link to pdf.

https://h21007.www2.hpe.com/portal/download/files/unprot/hpux/MakingConditionVariablesPerform.pdf

-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Qusetions] How profile affect glusterfs performance?

[Pranith Kumar Karampuri]

What is your usecase if I may ask?

On Mon, Jun 5, 2017 at 11:08 AM, Xie Changlong <xiechanglon...@gmail.com>
wrote:

> 在 6/5/2017 1:22 PM, Pranith Kumar Karampuri 写道:
>
>> On Mon, Jun 5, 2017 at 8:29 AM, Xie Changlong <xiechanglon...@gmail.com>
>> wrote:
>>
>> 在 6/5/2017 10:50 AM, Pranith Kumar Karampuri 写道:
>>>
>>> I think there have been improvements here to use special instructions to
>>>>
>>>>
>>> if "special instructions" means profile command or more? Also can you
>>> point which commit?
>>>
>>>
>> I meant Intel CPU extentions
>> You should look at
>> http://review.gluster.org/12209
>> http://review.gluster.org/12210
>> https://review.gluster.org/16963
>> https://review.gluster.org/17009
>>
>
> Useful enough for me, thanks for your patience.
>
>
>>
>> do the increments instead of taking spin-locks and doing increments. So
>>>
>>>> may be it doesn't affect performance as much anymore. I think if you
>>>> don't
>>>> see a difference, then the enhancements are doing a good job :-).
>>>>
>>>> Which version of gluster are you using?
>>>>
>>>>
>>> Our version is gluster 3.8.4
>>>
>>> --
>>> Thanks
>>>  -Xie
>>>
>>>
>>
>>
>>
> --
> Thanks
> -Xie
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Adding one variable to inode structure

[Pranith Kumar Karampuri]

On Mon, Jun 5, 2017 at 11:24 AM, Tahereh Fattahi <t28.fatt...@gmail.com>
wrote:

> Thank you
> I see that this xlator is loaded in server side.
> How can I access to variable in index xlator in client side?
> is it correct? getfattr trusted.index.myvar
>

To which xlator do you want this information? Or do you want this on mount?


>
> On Mon, Jun 5, 2017 at 10:00 AM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>>
>>
>> On Mon, Jun 5, 2017 at 9:55 AM, Tahereh Fattahi <t28.fatt...@gmail.com>
>> wrote:
>>
>>> Assume that one client wants to search it's directories for video files.
>>>  I want use something that helps this client to search just directories
>>> that have this kind of file.
>>> like a extended attribute, but I want this attribute be set by server
>>> not by client.
>>> I dont know which xlator is suitable for this work.
>>>
>>
>> The xlator that comes close to it is:  index xlator
>> xlators/features/index/src
>>
>> You may have to track extra operations like create/mknod/link/rename/unlink
>> to make sure you get the functionality you want. Basically this xlator
>> helps you in indexing a behavior. We use this for indexing
>> directories/files that need heal etc.
>>
>>
>>>
>>> On Mon, Jun 5, 2017 at 7:13 AM, Pranith Kumar Karampuri <
>>> pkara...@redhat.com> wrote:
>>>
>>>> This sounds hacky. In general anything that is specific about an inode,
>>>> we try to store it in inode-ctx. Who uses this information about presence
>>>> of video-file and how? May be with that knowledge there could be a
>>>> possibility we can improve the solution. Do let us know the complete
>>>> problem you are trying to solve.
>>>>
>>>> On Mon, Jun 5, 2017 at 4:53 AM, Tahereh Fattahi <t28.fatt...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi
>>>>> I want to add one boolean field to inode structure for a directory.
>>>>>  when it is 1 it means that directory has one or more video file. when
>>>>> it is 0 it means that there is no video file in that directory.
>>>>> I can add this variable to inode structure and update it in server
>>>>> side, in posix_create function (when there is a create request for a video
>>>>> file).
>>>>> question is about client knowledge about this variable. is it possible
>>>>> that client can see the amount of this variable of different servers
>>>>> (bricks) and OR them to one variable in cient's inode of the directory? in
>>>>> which xlator I should try in client side?
>>>>>
>>>>> ___
>>>>> Gluster-devel mailing list
>>>>> Gluster-devel@gluster.org
>>>>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Pranith
>>>>
>>>
>>>
>>
>>
>> --
>> Pranith
>>
>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Adding one variable to inode structure

[Pranith Kumar Karampuri]

Oh you want applications to do getfattr to find that it is there?

I think I understood what you are looking for now. So basically
applications will keep doing creation of some files/directories, whenever a
video file is created you want the bricks to set an extended attribute on
the directory, so that the application can use it. I don't think this
doesn't look like the job of index xlator either.

Why do you not want to set the extended attribute from client and want the
fs to do it on-behalf of the application? Setting it from client has
benefits like even when one brick is down it will automatically heal this
extended attribute etc.

On Mon, Jun 5, 2017 at 12:10 PM, Tahereh Fattahi <t28.fatt...@gmail.com>
wrote:

> I want in in mount directory in client side
>
> On Mon, Jun 5, 2017 at 11:07 AM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>>
>>
>> On Mon, Jun 5, 2017 at 11:24 AM, Tahereh Fattahi <t28.fatt...@gmail.com>
>> wrote:
>>
>>> Thank you
>>> I see that this xlator is loaded in server side.
>>> How can I access to variable in index xlator in client side?
>>> is it correct? getfattr trusted.index.myvar
>>>
>>
>> To which xlator do you want this information? Or do you want this on
>> mount?
>>
>>
>>>
>>> On Mon, Jun 5, 2017 at 10:00 AM, Pranith Kumar Karampuri <
>>> pkara...@redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jun 5, 2017 at 9:55 AM, Tahereh Fattahi <t28.fatt...@gmail.com>
>>>> wrote:
>>>>
>>>>> Assume that one client wants to search it's directories for video
>>>>> files.
>>>>>  I want use something that helps this client to search just
>>>>> directories that have this kind of file.
>>>>> like a extended attribute, but I want this attribute be set by server
>>>>> not by client.
>>>>> I dont know which xlator is suitable for this work.
>>>>>
>>>>
>>>> The xlator that comes close to it is:  index xlator
>>>> xlators/features/index/src
>>>>
>>>> You may have to track extra operations like
>>>> create/mknod/link/rename/unlink to make sure you get the functionality
>>>> you want. Basically this xlator helps you in indexing a behavior. We use
>>>> this for indexing directories/files that need heal etc.
>>>>
>>>>
>>>>>
>>>>> On Mon, Jun 5, 2017 at 7:13 AM, Pranith Kumar Karampuri <
>>>>> pkara...@redhat.com> wrote:
>>>>>
>>>>>> This sounds hacky. In general anything that is specific about an
>>>>>> inode, we try to store it in inode-ctx. Who uses this information about
>>>>>> presence of video-file and how? May be with that knowledge there could 
>>>>>> be a
>>>>>> possibility we can improve the solution. Do let us know the complete
>>>>>> problem you are trying to solve.
>>>>>>
>>>>>> On Mon, Jun 5, 2017 at 4:53 AM, Tahereh Fattahi <
>>>>>> t28.fatt...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>> I want to add one boolean field to inode structure for a directory.
>>>>>>>  when it is 1 it means that directory has one or more video file.
>>>>>>> when it is 0 it means that there is no video file in that directory.
>>>>>>> I can add this variable to inode structure and update it in server
>>>>>>> side, in posix_create function (when there is a create request for a 
>>>>>>> video
>>>>>>> file).
>>>>>>> question is about client knowledge about this variable. is it
>>>>>>> possible that client can see the amount of this variable of different
>>>>>>> servers (bricks) and OR them to one variable in cient's inode of the
>>>>>>> directory? in which xlator I should try in client side?
>>>>>>>
>>>>>>> ___
>>>>>>> Gluster-devel mailing list
>>>>>>> Gluster-devel@gluster.org
>>>>>>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Pranith
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Pranith
>>>>
>>>
>>>
>>
>>
>> --
>> Pranith
>>
>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Qusetions] How profile affect glusterfs performance?

[Pranith Kumar Karampuri]

On Mon, Jun 5, 2017 at 8:29 AM, Xie Changlong <xiechanglon...@gmail.com>
wrote:

> 在 6/5/2017 10:50 AM, Pranith Kumar Karampuri 写道:
>
>> I think there have been improvements here to use special instructions to
>>
>
> if "special instructions" means profile command or more? Also can you
> point which commit?
>

I meant Intel CPU extentions
You should look at
http://review.gluster.org/12209
http://review.gluster.org/12210
https://review.gluster.org/16963
https://review.gluster.org/17009


> do the increments instead of taking spin-locks and doing increments. So
>> may be it doesn't affect performance as much anymore. I think if you don't
>> see a difference, then the enhancements are doing a good job :-).
>>
>> Which version of gluster are you using?
>>
>
> Our version is gluster 3.8.4
>
> --
> Thanks
> -Xie
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Adding one variable to inode structure

[Pranith Kumar Karampuri]

This sounds hacky. In general anything that is specific about an inode, we
try to store it in inode-ctx. Who uses this information about presence of
video-file and how? May be with that knowledge there could be a possibility
we can improve the solution. Do let us know the complete problem you are
trying to solve.

On Mon, Jun 5, 2017 at 4:53 AM, Tahereh Fattahi 
wrote:

> Hi
> I want to add one boolean field to inode structure for a directory.
>  when it is 1 it means that directory has one or more video file. when it
> is 0 it means that there is no video file in that directory.
> I can add this variable to inode structure and update it in server side,
> in posix_create function (when there is a create request for a video file).
> question is about client knowledge about this variable. is it possible
> that client can see the amount of this variable of different servers
> (bricks) and OR them to one variable in cient's inode of the directory? in
> which xlator I should try in client side?
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Qusetions] How profile affect glusterfs performance?

[Pranith Kumar Karampuri]

I think there have been improvements here to use special instructions to do
the increments instead of taking spin-locks and doing increments. So may be
it doesn't affect performance as much anymore. I think if you don't see a
difference, then the enhancements are doing a good job :-).

Which version of gluster are you using?

On Mon, Jun 5, 2017 at 8:09 AM, Xie Changlong 
wrote:

> Hi all
>
> It's said[1] that profile based on io-stats, if you enable this feature,
> it can affect system performance while the profile information is being
> collected.
>
> I do some tests on my two linux+vmware virtual machine with replica(lack
> of resources ). And the results shows no diffrence to me, following is the
> test case
> #dd if=/dev/zero  of=test bs=4k count=524288
> #fio --filename=test -iodepth=64 -ioengine=libaio --direct=1 --rw=read
> --bs=1m --size=2g --numjobs=4 --runtime=10 --group_reporting
> --name=test-read
> #fio -filename=test -iodepth=64 -ioengine=libaio -direct=1 -rw=write
> -bs=1m -size=2g -numjobs=4 -runtime=20 -group_reporting -name=test-write
> #fio -filename=test -iodepth=64 -ioengine=libaio -direct=1 -rw=randread
> -bs=4k -size=2G -numjobs=64 -runtime=20 -group_reporting
> -name=test-rand-read
> #fio -filename=test -iodepth=64 -ioengine=libaio -direct=1 -rw=randwrite
> -bs=4k -size=2G -numjobs=64 -runtime=20 -group_reporting
> -name=test-rand-write
> It's said that fio is only for lagre files, also i suspect that the test
> infrastructure is too small. The question is that, if you guys have
> detailed data for how profile affect performance?
>
> More, we wanna gain the detail r/w iops/bandwidth data for each brick. It
> seems that only profile can provide relatived data to be calculated?if i'm
> wrong pls corrent me.
>
> If profile really affect peformance so much, would you mind a new command
> such as "gluster volume io [nfs]" to acquire brick r/w fops/data? Or just
> help us review it?
>
> [1] https://access.redhat.com/documentation/en-us/red_hat_gluste
> r_storage/3.2/html/administration_guide/chap-monitoring_red_
> hat_storage_workload#sect-Running_the_Volume_Profile_Command
> --
> Thanks
> -Xie
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Adding one variable to inode structure

[Pranith Kumar Karampuri]

On Mon, Jun 5, 2017 at 9:55 AM, Tahereh Fattahi <t28.fatt...@gmail.com>
wrote:

> Assume that one client wants to search it's directories for video files.
>  I want use something that helps this client to search just directories
> that have this kind of file.
> like a extended attribute, but I want this attribute be set by server not
> by client.
> I dont know which xlator is suitable for this work.
>

The xlator that comes close to it is:  index xlator
xlators/features/index/src

You may have to track extra operations like create/mknod/link/rename/unlink
to make sure you get the functionality you want. Basically this xlator
helps you in indexing a behavior. We use this for indexing
directories/files that need heal etc.


>
> On Mon, Jun 5, 2017 at 7:13 AM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>> This sounds hacky. In general anything that is specific about an inode,
>> we try to store it in inode-ctx. Who uses this information about presence
>> of video-file and how? May be with that knowledge there could be a
>> possibility we can improve the solution. Do let us know the complete
>> problem you are trying to solve.
>>
>> On Mon, Jun 5, 2017 at 4:53 AM, Tahereh Fattahi <t28.fatt...@gmail.com>
>> wrote:
>>
>>> Hi
>>> I want to add one boolean field to inode structure for a directory.
>>>  when it is 1 it means that directory has one or more video file. when
>>> it is 0 it means that there is no video file in that directory.
>>> I can add this variable to inode structure and update it in server side,
>>> in posix_create function (when there is a create request for a video file).
>>> question is about client knowledge about this variable. is it possible
>>> that client can see the amount of this variable of different servers
>>> (bricks) and OR them to one variable in cient's inode of the directory? in
>>> which xlator I should try in client side?
>>>
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>>
>> --
>> Pranith
>>
>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release 3.11: Has been Branched (and pending feature notes)

[Pranith Kumar Karampuri]

On Wed, May 3, 2017 at 2:36 PM, Kaushal M <kshlms...@gmail.com> wrote:

> On Tue, May 2, 2017 at 3:55 PM, Pranith Kumar Karampuri
> <pkara...@redhat.com> wrote:
> >
> >
> > On Sun, Apr 30, 2017 at 9:01 PM, Shyam <srang...@redhat.com> wrote:
> >>
> >> Hi,
> >>
> >> Release 3.11 for gluster has been branched [1] and tagged [2].
> >>
> >> We have ~4weeks to release of 3.11, and a week to backport features that
> >> slipped the branching date (May-5th).
> >>
> >> A tracker BZ [3] has been opened for *blockers* of 3.11 release. Request
> >> that any bug that is determined as a blocker for the release be noted
> as a
> >> "blocks" against this bug.
> >>
> >> NOTE: Just a heads up, all bugs that are to be backported in the next 4
> >> weeks need not be reflected against the blocker, *only* blocker bugs
> >> identified that should prevent the release, need to be tracked against
> this
> >> tracker bug.
> >>
> >> We are not building beta1 packages, and will build out RC0 packages once
> >> we cross the backport dates. Hence, folks interested in testing this
> out can
> >> either build from the code or wait for (about) a week longer for the
> >> packages (and initial release notes).
> >>
> >> Features tracked as slipped and expected to be backported by 5th May
> are,
> >>
> >> 1) [RFE] libfuse rebase to latest? #153 (@amar, @csaba)
> >>
> >> 2) SELinux support for Gluster Volumes #55 (@ndevos, @jiffin)
> >>   - Needs a +2 on https://review.gluster.org/13762
> >>
> >> 3) Enhance handleops readdirplus operation to return handles along with
> >> dirents #174 (@skoduri)
> >>
> >> 4) Halo - Initial version (@pranith)
> >
> >
> > I merged the patch on master. Will send out the port on Thursday. I have
> to
> > leave like right now to catch train and am on leave tomorrow, so will be
> > back on Thursday and get the port done. Will also try to get the other
> > patches fb guys mentioned post that preferably by 5th itself.
>
> Niels found that the HALO patch has pulled in a little bit of the IPv6
> patch. This shouldn't have happened.
> The IPv6 patch is currently stalled because it depends on an internal
> FB library. The IPv6 bits that made it in pull this dependency.
> This would have lead to a -2 on the HALO patch by me, but as I wasn't
> aware of it, the patch was merged.
>
> The IPV6 changes are in rpcsvh.{c,h} and configure.ac, and don't seem
> to affect anything HALO. So they should be easily removable and should
> be removed.
>

As per the configure.ac the macro is enabled only when we are building
gluster with "--with-fb-extras", which I don't think we do anywhere, so
didn't think they are important at the moment. Sorry for the confusion
caused because of this. Thanks to Kaushal for the patch. I will backport
that one as well when I do the 3.11 backport of HALO. So will wait for the
backport until Kaushal's patch is merged.



>
> >
> >>
> >>
> >> Thanks,
> >> Kaushal, Shyam
> >>
> >> [1] 3.11 Branch: https://github.com/gluster/glusterfs/tree/release-3.11
> >>
> >> [2] Tag for 3.11.0beta1 :
> >> https://github.com/gluster/glusterfs/tree/v3.11.0beta1
> >>
> >> [3] Tracker BZ for 3.11.0 blockers:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.11.0
> >>
> >> ___
> >> maintainers mailing list
> >> maintain...@gluster.org
> >> http://lists.gluster.org/mailman/listinfo/maintainers
> >
> >
> >
> >
> > --
> > Pranith
> >
> > ___
> > Gluster-devel mailing list
> > Gluster-devel@gluster.org
> > http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] [DHT] The myth of two hops for linkto file resolution

[Pranith Kumar Karampuri]

On Sun, Apr 30, 2017 at 9:33 AM, Raghavendra Gowdappa 
wrote:

> All,
>
> Its a common perception that the resolution of a file having linkto file
> on the hashed-subvol requires two hops:
>
> 1. client to hashed-subvol.
> 2. client to the subvol where file actually resides.
>
> While it is true that a fresh lookup behaves this way, the other fact that
> get's ignored is that fresh lookups on files are almost always prevented by
> readdirplus. Since readdirplus picks the dentry from the subvolume where
> actual file (data-file) resides, the two hop cost is most likely never
> witnessed by the application.
>
> A word of caution is that I've not done any testing to prove this
> observation :).
>

May be you should do it and send an update. That way we can use the
knowledge to do something.


>
> regards,
> Raghavendra
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Enabling shard on EC

[Pranith Kumar Karampuri]

It is never been tested. That said, I don't see any missing pieces that we
know of for it to work. Please note that sharding works only for single
writer cases at the moment. Do let us know if you find any problems and we
will fix them.

On Wed, May 3, 2017 at 2:17 PM, Ankireddypalle Reddy 
wrote:

> Hi,
>
>   Are there any known negatives of enabling shard on EC. Is this a
> recommended configuration?.
>
>
>
> Thanks and Regards,
>
> Ram
>
>
>
>
> ***Legal Disclaimer***
> "This communication may contain confidential and privileged material for
> the
> sole use of the intended recipient. Any unauthorized review, use or
> distribution
> by others is strictly prohibited. If you have received the message by
> mistake,
> please advise the sender by reply email and delete the message. Thank you."
> **
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Enabling shard on EC

[Pranith Kumar Karampuri]

On Thu, May 4, 2017 at 3:43 PM, Ankireddypalle Reddy <are...@commvault.com>
wrote:

> Pranith,
>
>  Thanks. Does it mean that a given file can be written by
> only one client at a time. If multiple clients try to access the file in
> write mode, does it lead to any kind of data inconsistencies.
>

We only tested it for single writer cases such as VM usecases. We need to
bring in transaction framework for sharding to work with multiple writers.


>
>
> Thanks and Regards,
>
> Ram
>
> *From:* Pranith Kumar Karampuri [mailto:pkara...@redhat.com]
> *Sent:* Thursday, May 04, 2017 6:07 AM
> *To:* Ankireddypalle Reddy
> *Cc:* Gluster Devel (gluster-devel@gluster.org); gluster-us...@gluster.org
> *Subject:* Re: [Gluster-devel] Enabling shard on EC
>
>
>
> It is never been tested. That said, I don't see any missing pieces that we
> know of for it to work. Please note that sharding works only for single
> writer cases at the moment. Do let us know if you find any problems and we
> will fix them.
>
>
>
> On Wed, May 3, 2017 at 2:17 PM, Ankireddypalle Reddy <are...@commvault.com>
> wrote:
>
> Hi,
>
>   Are there any known negatives of enabling shard on EC. Is this a
> recommended configuration?.
>
>
>
> Thanks and Regards,
>
> Ram
>
>
>
>
>
> ***Legal Disclaimer***
>
> "This communication may contain confidential and privileged material for
> the
>
> sole use of the intended recipient. Any unauthorized review, use or
> distribution
>
> by others is strictly prohibited. If you have received the message by
> mistake,
>
> please advise the sender by reply email and delete the message. Thank you."
>
> **
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
>
>
> --
>
> Pranith
> ***Legal Disclaimer***
> "This communication may contain confidential and privileged material for
> the
> sole use of the intended recipient. Any unauthorized review, use or
> distribution
> by others is strictly prohibited. If you have received the message by
> mistake,
> please advise the sender by reply email and delete the message. Thank you."
> **
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Don't allow data loss via add-brick (was Re: [Gluster-users] Add single server)

[Pranith Kumar Karampuri]

Yeah it is a good idea. I asked him to raise a bug and we can move forward
with it.

On Mon, May 1, 2017 at 9:07 PM, Joe Julian  wrote:

>
> On 04/30/2017 01:13 AM, lemonni...@ulrar.net wrote:
>
>> So I was a little but luck. If I has all the hardware part, probably i
>>> would be firesd after causing data loss by using a software marked as
>>> stable
>>>
>> Yes, we lost our data last year to this bug, and it wasn't a test cluster.
>> We still hear from it from our clients to this day.
>>
>> Is known that this feature is causing data loss and there is no evidence
>>> or
>>> no warning in official docs.
>>>
>>> I was (I believe) the first one to run into the bug, it happens and I
>> knew it
>> was a risk when installing gluster.
>> But since then I didn't see any warnings anywhere except here, I agree
>> with you that it should be mentionned in big bold letters on the site.
>>
>> Might even be worth adding a warning directly on the cli when trying to
>> add bricks if sharding is enabled, to make sure no-one will destroy a
>> whole cluster for a known bug.
>>
>
> I absolutely agree - or, just disable the ability to add-brick with
> sharding enabled. Losing data should never be allowed.
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release 3.11: Has been Branched (and pending feature notes)

[Pranith Kumar Karampuri]

On Sun, Apr 30, 2017 at 9:01 PM, Shyam  wrote:

> Hi,
>
> Release 3.11 for gluster has been branched [1] and tagged [2].
>
> We have ~4weeks to release of 3.11, and a week to backport features that
> slipped the branching date (May-5th).
>
> A tracker BZ [3] has been opened for *blockers* of 3.11 release. Request
> that any bug that is determined as a blocker for the release be noted as a
> "blocks" against this bug.
>
> NOTE: Just a heads up, all bugs that are to be backported in the next 4
> weeks need not be reflected against the blocker, *only* blocker bugs
> identified that should prevent the release, need to be tracked against this
> tracker bug.
>
> We are not building beta1 packages, and will build out RC0 packages once
> we cross the backport dates. Hence, folks interested in testing this out
> can either build from the code or wait for (about) a week longer for the
> packages (and initial release notes).
>
> Features tracked as slipped and expected to be backported by 5th May are,
>
> 1) [RFE] libfuse rebase to latest? #153 (@amar, @csaba)
>
> 2) SELinux support for Gluster Volumes #55 (@ndevos, @jiffin)
>   - Needs a +2 on https://review.gluster.org/13762
>
> 3) Enhance handleops readdirplus operation to return handles along with
> dirents #174 (@skoduri)
>
> 4) Halo - Initial version (@pranith)
>

I merged the patch on master. Will send out the port on Thursday. I have to
leave like right now to catch train and am on leave tomorrow, so will be
back on Thursday and get the port done. Will also try to get the other
patches fb guys mentioned post that preferably by 5th itself.


>
> Thanks,
> Kaushal, Shyam
>
> [1] 3.11 Branch: https://github.com/gluster/glusterfs/tree/release-3.11
>
> [2] Tag for 3.11.0beta1 : https://github.com/gluster/glu
> sterfs/tree/v3.11.0beta1
>
> [3] Tracker BZ for 3.11.0 blockers: https://bugzilla.redhat.com/sh
> ow_bug.cgi?id=glusterfs-3.11.0
>
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Don't allow data loss via add-brick (was Re: Add single server)

[Pranith Kumar Karampuri]

On Tue, May 2, 2017 at 9:16 AM, Pranith Kumar Karampuri <pkara...@redhat.com
> wrote:

> Yeah it is a good idea. I asked him to raise a bug and we can move forward
> with it.
>

+Raghavendra/Nitya who can help with the fix.


>
> On Mon, May 1, 2017 at 9:07 PM, Joe Julian <j...@julianfamily.org> wrote:
>
>>
>> On 04/30/2017 01:13 AM, lemonni...@ulrar.net wrote:
>>
>>> So I was a little but luck. If I has all the hardware part, probably i
>>>> would be firesd after causing data loss by using a software marked as
>>>> stable
>>>>
>>> Yes, we lost our data last year to this bug, and it wasn't a test
>>> cluster.
>>> We still hear from it from our clients to this day.
>>>
>>> Is known that this feature is causing data loss and there is no evidence
>>>> or
>>>> no warning in official docs.
>>>>
>>>> I was (I believe) the first one to run into the bug, it happens and I
>>> knew it
>>> was a risk when installing gluster.
>>> But since then I didn't see any warnings anywhere except here, I agree
>>> with you that it should be mentionned in big bold letters on the site.
>>>
>>> Might even be worth adding a warning directly on the cli when trying to
>>> add bricks if sharding is enabled, to make sure no-one will destroy a
>>> whole cluster for a known bug.
>>>
>>
>> I absolutely agree - or, just disable the ability to add-brick with
>> sharding enabled. Losing data should never be allowed.
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Pranith
>
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Enabling shard on EC

[Pranith Kumar Karampuri]

+Krutika

Krutika started work on this. But it is very long term. Not a simple thing
to do.

On Thu, May 4, 2017 at 3:53 PM, Ankireddypalle Reddy <are...@commvault.com>
wrote:

> Pranith,
>
>  Thanks. Is there any work in progress to add this support.
>
>
>
> Thanks and Regards,
>
> Ram
>
> *From:* Pranith Kumar Karampuri [mailto:pkara...@redhat.com]
> *Sent:* Thursday, May 04, 2017 6:17 AM
>
> *To:* Ankireddypalle Reddy
> *Cc:* Gluster Devel (gluster-devel@gluster.org); gluster-us...@gluster.org
> *Subject:* Re: [Gluster-devel] Enabling shard on EC
>
>
>
>
>
>
>
> On Thu, May 4, 2017 at 3:43 PM, Ankireddypalle Reddy <are...@commvault.com>
> wrote:
>
> Pranith,
>
>  Thanks. Does it mean that a given file can be written by
> only one client at a time. If multiple clients try to access the file in
> write mode, does it lead to any kind of data inconsistencies.
>
>
>
> We only tested it for single writer cases such as VM usecases. We need to
> bring in transaction framework for sharding to work with multiple writers.
>
>
>
>
>
> Thanks and Regards,
>
> Ram
>
> *From:* Pranith Kumar Karampuri [mailto:pkara...@redhat.com]
> *Sent:* Thursday, May 04, 2017 6:07 AM
> *To:* Ankireddypalle Reddy
> *Cc:* Gluster Devel (gluster-devel@gluster.org); gluster-us...@gluster.org
> *Subject:* Re: [Gluster-devel] Enabling shard on EC
>
>
>
> It is never been tested. That said, I don't see any missing pieces that we
> know of for it to work. Please note that sharding works only for single
> writer cases at the moment. Do let us know if you find any problems and we
> will fix them.
>
>
>
> On Wed, May 3, 2017 at 2:17 PM, Ankireddypalle Reddy <are...@commvault.com>
> wrote:
>
> Hi,
>
>   Are there any known negatives of enabling shard on EC. Is this a
> recommended configuration?.
>
>
>
> Thanks and Regards,
>
> Ram
>
>
>
>
>
> ***Legal Disclaimer***
>
> "This communication may contain confidential and privileged material for
> the
>
> sole use of the intended recipient. Any unauthorized review, use or
> distribution
>
> by others is strictly prohibited. If you have received the message by
> mistake,
>
> please advise the sender by reply email and delete the message. Thank you."
>
> **
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
>
>
> --
>
> Pranith
>
> ***Legal Disclaimer***
>
> "This communication may contain confidential and privileged material for
> the
>
> sole use of the intended recipient. Any unauthorized review, use or
> distribution
>
> by others is strictly prohibited. If you have received the message by
> mistake,
>
> please advise the sender by reply email and delete the message. Thank you."
>
> **
>
>
>
>
> --
>
> Pranith
> ***Legal Disclaimer***
> "This communication may contain confidential and privileged material for
> the
> sole use of the intended recipient. Any unauthorized review, use or
> distribution
> by others is strictly prohibited. If you have received the message by
> mistake,
> please advise the sender by reply email and delete the message. Thank you."
> **
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Release 3.11: Has been Branched (and pending feature notes)

[Pranith Kumar Karampuri]

I merged this and posted the backport merging the two patches into one:
https://review.gluster.org/#/c/17192
Regressions started just now.

On Fri, May 5, 2017 at 3:31 PM, Kaushal M <kshlms...@gmail.com> wrote:

> On Thu, May 4, 2017 at 6:40 PM, Kaushal M <kshlms...@gmail.com> wrote:
> > On Thu, May 4, 2017 at 4:38 PM, Niels de Vos <nde...@redhat.com> wrote:
> >> On Thu, May 04, 2017 at 03:39:58PM +0530, Pranith Kumar Karampuri wrote:
> >>> On Wed, May 3, 2017 at 2:36 PM, Kaushal M <kshlms...@gmail.com> wrote:
> >>>
> >>> > On Tue, May 2, 2017 at 3:55 PM, Pranith Kumar Karampuri
> >>> > <pkara...@redhat.com> wrote:
> >>> > >
> >>> > >
> >>> > > On Sun, Apr 30, 2017 at 9:01 PM, Shyam <srang...@redhat.com>
> wrote:
> >>> > >>
> >>> > >> Hi,
> >>> > >>
> >>> > >> Release 3.11 for gluster has been branched [1] and tagged [2].
> >>> > >>
> >>> > >> We have ~4weeks to release of 3.11, and a week to backport
> features that
> >>> > >> slipped the branching date (May-5th).
> >>> > >>
> >>> > >> A tracker BZ [3] has been opened for *blockers* of 3.11 release.
> Request
> >>> > >> that any bug that is determined as a blocker for the release be
> noted
> >>> > as a
> >>> > >> "blocks" against this bug.
> >>> > >>
> >>> > >> NOTE: Just a heads up, all bugs that are to be backported in the
> next 4
> >>> > >> weeks need not be reflected against the blocker, *only* blocker
> bugs
> >>> > >> identified that should prevent the release, need to be tracked
> against
> >>> > this
> >>> > >> tracker bug.
> >>> > >>
> >>> > >> We are not building beta1 packages, and will build out RC0
> packages once
> >>> > >> we cross the backport dates. Hence, folks interested in testing
> this
> >>> > out can
> >>> > >> either build from the code or wait for (about) a week longer for
> the
> >>> > >> packages (and initial release notes).
> >>> > >>
> >>> > >> Features tracked as slipped and expected to be backported by 5th
> May
> >>> > are,
> >>> > >>
> >>> > >> 1) [RFE] libfuse rebase to latest? #153 (@amar, @csaba)
> >>> > >>
> >>> > >> 2) SELinux support for Gluster Volumes #55 (@ndevos, @jiffin)
> >>> > >>   - Needs a +2 on https://review.gluster.org/13762
> >>> > >>
> >>> > >> 3) Enhance handleops readdirplus operation to return handles
> along with
> >>> > >> dirents #174 (@skoduri)
> >>> > >>
> >>> > >> 4) Halo - Initial version (@pranith)
> >>> > >
> >>> > >
> >>> > > I merged the patch on master. Will send out the port on Thursday.
> I have
> >>> > to
> >>> > > leave like right now to catch train and am on leave tomorrow, so
> will be
> >>> > > back on Thursday and get the port done. Will also try to get the
> other
> >>> > > patches fb guys mentioned post that preferably by 5th itself.
> >>> >
> >>> > Niels found that the HALO patch has pulled in a little bit of the
> IPv6
> >>> > patch. This shouldn't have happened.
> >>> > The IPv6 patch is currently stalled because it depends on an internal
> >>> > FB library. The IPv6 bits that made it in pull this dependency.
> >>> > This would have lead to a -2 on the HALO patch by me, but as I wasn't
> >>> > aware of it, the patch was merged.
> >>> >
> >>> > The IPV6 changes are in rpcsvh.{c,h} and configure.ac, and don't
> seem
> >>> > to affect anything HALO. So they should be easily removable and
> should
> >>> > be removed.
> >>> >
> >>>
> >>> As per the configure.ac the macro is enabled only when we are building
> >>> gluster with "--with-fb-extras", which I don't think we do anywhere, so
> >>> didn't think they are important at the moment. Sorry for the confusion
> >>> caused because of this. Thanks to Kaushal for the patch. I will
> backport
> >&

Re: [Gluster-devel] tests/basic/pump.t - what is it used for?

[Pranith Kumar Karampuri]

It was used for testing pump xlator functionality. When replace-brick is
done on a distribute volume, it would lead to pump xlator migrating data to
the destination brick from source. I guess we can delete this test. I don't
think we support pump xlator anymore.

On Fri, Sep 8, 2017 at 10:02 AM, Atin Mukherjee  wrote:

> Pranith,
>
> I see you're the author of the test in $Subj. Now while I was working on a
> patch https://review.gluster.org/#/c/18226/ to disallow replace brick
> operations on dist only volumes the patch failed the regression on this
> test as the test actually uses replace brick on a distribute only volume
> which IMO is wrong as then this would always end up in to data loss
> situation. I'd need some context here to understand the expectation of this
> test before doing any modifications.
>
> ~Atin
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Need help figuring out the reason for test failure

[Pranith Kumar Karampuri]

On Tue, Nov 28, 2017 at 9:07 AM, Nigel Babu <nig...@redhat.com> wrote:

> Pranith,
>
> Our logging has changed slightly. Please read my email titled "Changes in
> handling logs from (centos) regressions and smoke" to gluster-devel and
> gluster-infra.
>

Thanks for the pointer. Able to get the logs now!


>
> On Tue, Nov 28, 2017 at 8:06 AM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>> One of my patches(https://review.gluster.org/18857) is consistently
>> leading to a failure for the test:
>>
>> tests/bugs/core/bug-1432542-mpx-restart-crash.t
>>
>> https://build.gluster.org/job/centos6-regression/7676/consoleFull
>>
>> Jeff/Atin,
>> Do you know anything about these kinds of failures for this test?
>>
>> Nigel,
>>Unfortunately I am not able to look at the logs because the logs
>> location is not given properly (at least for me :-) )
>>
>> *11:41:14* 
>> filename="${ARCHIVED_LOGS}/glusterfs-logs-${UNIQUE_ID}.tgz"*11:41:14* sudo 
>> -E tar -czf "${ARCHIVE_BASE}/${filename}" /var/log/glusterfs 
>> /var/log/messages*;*11:41:14* echo "Logs archived in 
>> http://${SERVER}/${filename};
>>
>>
>> Could you help me find what the location could be?
>> --
>> Pranith
>>
>
>
>
> --
> nigelb
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Need help figuring out the reason for test failure

[Pranith Kumar Karampuri]

One of my patches(https://review.gluster.org/18857) is consistently leading
to a failure for the test:

tests/bugs/core/bug-1432542-mpx-restart-crash.t

https://build.gluster.org/job/centos6-regression/7676/consoleFull

Jeff/Atin,
Do you know anything about these kinds of failures for this test?

Nigel,
   Unfortunately I am not able to look at the logs because the logs
location is not given properly (at least for me :-) )

*11:41:14* filename="${ARCHIVED_LOGS}/glusterfs-logs-${UNIQUE_ID}.tgz"*11:41:14*
sudo -E tar -czf "${ARCHIVE_BASE}/${filename}" /var/log/glusterfs
/var/log/messages*;*11:41:14* echo "Logs archived in
http://${SERVER}/${filename};


Could you help me find what the location could be?
-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] reflink support for glusterfs and gluster-block using it for taking snapshots

[Pranith Kumar Karampuri]

hi,
 I just created a github issue for reflink support
(#349) in glusterfs. We
are intending to use this feature to do block snapshots in gluster-block.

Please let us know your comments on the github issue. I have added the
changes we may need for xlators I know a little bit about. Please help in
identifying gaps in implementing this FOP.

-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Thin-arbiter design to solve stretch cluster usecase

[Pranith Kumar Karampuri]

hi,
 I created a new issue 
which shares a link of design document for this feature. Please add
comments to the design document itself rather than github issue, so that
all comments are in one place.

Thanks in advance.

-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Tie-breaker logic for blocking inodelks/entrylks

[Pranith Kumar Karampuri]

I got a +1 from Ashish and Xavi for the idea. I will wait for people from
other time zones to comment on the same and will start implementing the
solution tomorrow morning IST. I am kind of in a hurry to get this done,
preferably by end of this week.

Thanks in advance.

On Thu, Nov 9, 2017 at 8:56 AM, Pranith Kumar Karampuri <pkara...@redhat.com
> wrote:

> This github issue <https://github.com/gluster/glusterfs/issues/354> talks
> about the logic for implementing tie-breaker logic for blocking
> inodelks/entrylks. Your comments are welcome on the issue.
>
> --
> Pranith
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Tie-breaker logic for blocking inodelks/entrylks

[Pranith Kumar Karampuri]

This github issue  talks
about the logic for implementing tie-breaker logic for blocking
inodelks/entrylks. Your comments are welcome on the issue.

-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reflink support for glusterfs and gluster-block using it for taking snapshots

[Pranith Kumar Karampuri]

On Tue, Nov 7, 2017 at 5:16 PM, Niels de Vos <nde...@redhat.com> wrote:

> On Tue, Nov 07, 2017 at 07:43:17AM +0530, Pranith Kumar Karampuri wrote:
> > hi,
> >  I just created a github issue for reflink support
> > <https://github.com/gluster/glusterfs/issues/349>(#349) in glusterfs. We
> > are intending to use this feature to do block snapshots in gluster-block.
> >
> > Please let us know your comments on the github issue. I have added the
> > changes we may need for xlators I know a little bit about. Please help in
> > identifying gaps in implementing this FOP.
>
> For gluster-block it may be easier to have snapshot support in
> tcmu-runner instead? The qcow2 format would be ideal, and is in use by
> different Virtual Machine approaches running on Gluster already. There
> even is an upstream issue open for it:
>   https://github.com/open-iscsi/tcmu-runner/issues/32
>
> Contributing towards this might be quicker than implementing file
> snapshot support in Gluster?
>

We tried that route by talking Fam Zheng, but the solution won't be
delivered in the timelines we are looking for.
So we went with this approach.


>
> Niels
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] reflink support for glusterfs and gluster-block using it for taking snapshots

[Pranith Kumar Karampuri]

On Thu, Nov 9, 2017 at 8:26 PM, Niels de Vos <nde...@redhat.com> wrote:

> On Tue, Nov 07, 2017 at 05:59:32PM +0530, Pranith Kumar Karampuri wrote:
> > On Tue, Nov 7, 2017 at 5:16 PM, Niels de Vos <nde...@redhat.com> wrote:
> >
> > > On Tue, Nov 07, 2017 at 07:43:17AM +0530, Pranith Kumar Karampuri
> wrote:
> > > > hi,
> > > >  I just created a github issue for reflink support
> > > > <https://github.com/gluster/glusterfs/issues/349>(#349) in
> glusterfs. We
> > > > are intending to use this feature to do block snapshots in
> gluster-block.
> > > >
> > > > Please let us know your comments on the github issue. I have added
> the
> > > > changes we may need for xlators I know a little bit about. Please
> help in
> > > > identifying gaps in implementing this FOP.
> > >
> > > For gluster-block it may be easier to have snapshot support in
> > > tcmu-runner instead? The qcow2 format would be ideal, and is in use by
> > > different Virtual Machine approaches running on Gluster already. There
> > > even is an upstream issue open for it:
> > >   https://github.com/open-iscsi/tcmu-runner/issues/32
> > >
> > > Contributing towards this might be quicker than implementing file
> > > snapshot support in Gluster?
> > >
> >
> > We tried that route by talking Fam Zheng, but the solution won't be
> > delivered in the timelines we are looking for.
> > So we went with this approach.
>
> Ok, I am not sure if adding support for reflink in Gluster has an
> immediate benefit. It surely would be a great feature to have, but I do
> not know if it will land in enterprise kernels soon.
>

https://github.com/gluster/glusterfs/issues/377 should address this concern
until reflink becomes mainstream.


>
> That said, I opened a GitHub issue to get reliable snapshot support in
> gluster-block. It describes an idea of the interface that could be
> implemented now already, without relying on reflink.
>
>   https://github.com/gluster/gluster-block/issues/42
>
> Obviously there is a need to sync/freeze data through tcmu-runner. This
> might require implementing a fsfreeze(8) like command in targetcli and
> tcmu-runner.
>
> Comments most welcome!
> Niels
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel