Re: [Gluster-devel] [Gluster-users] Feedback on DHT option "cluster.readdir-optimize"

[Nithya Balachandran]

On 8 November 2016 at 20:21, Kyle Johnson  wrote:

> Hey there,
>
> We have a number of processes which daily walk our entire directory tree
> and perform operations on the found files.
>
> Pre-gluster, this processes was able to complete within 24 hours of
> starting.  After outgrowing that single server and moving to a gluster
> setup (two bricks, two servers, distribute, 10gig uplink), the processes
> became unusable.
>
> After turning this option on, we were back to normal run times, with the
> process completing within 24 hours.
>
> Our data is heavy nested in a large number of subfolders under /media/ftp.
>

Thanks for getting back to us - this is very good information. Can you
provide a few more details?

How deep is your directory tree and roughly how many directories do you
have at each level?
Are all your files in the lowest level dirs or do they exist on several
levels?
Would you be willing to provide the gluster volume info output for this
volume?

>
> A subset of our data:
>
> 15T of files in 48163 directories under /media/ftp/dig_dis.
>
> Without readdir-optimize:
>
> [root@colossus dig_dis]# time ls|wc -l
> 48163
>
> real13m1.582s
> user0m0.294s
> sys 0m0.205s
>
>
> With readdir-optimize:
>
> [root@colossus dig_dis]# time ls | wc -l
> 48163
>
> real0m23.785s
> user0m0.296s
> sys 0m0.108s
>
>
> Long story short - this option is super important to me as it resolved an
> issue that would have otherwise made me move my data off of gluster.
>
>
> Thank you for all of your work,
>
> Kyle
>
>
>
>
>
> On 11/07/2016 10:07 PM, Raghavendra Gowdappa wrote:
>
>> Hi all,
>>
>> We have an option in called "cluster.readdir-optimize" which alters the
>> behavior of readdirp in DHT. This value affects how storage/posix treats
>> dentries corresponding to directories (not for files).
>>
>> When this value is on,
>> * DHT asks only one subvol/brick to return dentries corresponding to
>> directories.
>> * Other subvols/bricks filter dentries corresponding to directories and
>> send only dentries corresponding to files.
>>
>> When this value is off (this is the default value),
>> * All subvols return all dentries stored on them. IOW, bricks don't
>> filter any dentries.
>> * Since a directory has one dentry representing it on each subvol, dht
>> (loaded on client) picks up dentry only from hashed subvol.
>>
>> Note that irrespective of value of this option, _all_ subvols return
>> dentries corresponding to files which are stored on them.
>>
>> This option was introduced to boost performance of readdir as (when set
>> on), filtering of dentries happens on bricks and hence there is reduced:
>> 1. network traffic (with filtering all the redundant dentry information)
>> 2. number of readdir calls between client and server for the same number
>> of dentries returned to application (If filtering happens on client, lesser
>> number of dentries in result and hence more number of readdir calls. IOW,
>> result buffer is not filled to maximum capacity).
>>
>> We want to hear from you Whether you've used this option and if yes,
>> 1. Did it really boost readdir performance?
>> 2. Do you've any performance data to find out what was the percentage of
>> improvement (or deterioration)?
>> 3. Data set you had (Number of files, directories and organisation of
>> directories).
>>
>> If we find out that this option is really helping you, we can spend our
>> energies on fixing issues that will arise when this option is set to on.
>> One common issue with turning this option on is that when this option is
>> set, some directories might not show up in directory listing [1]. The
>> reason for this is that:
>> 1. If a directory can be created on a hashed subvol, mkdir (result to
>> application) will be successful, irrespective of result of mkdir on rest of
>> the subvols.
>> 2. So, any subvol we pick to give us dentries corresponding to directory
>> need not contain all the directories and we might miss out those
>> directories in listing.
>>
>> Your feedback is important for us and will help us to prioritize and
>> improve things.
>>
>> [1] https://www.gluster.org/pipermail/gluster-users/2016-October
>> /028703.html
>>
>> regards,
>> Raghavendra
>> ___
>> Gluster-users mailing list
>> gluster-us...@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-users
>>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Raghavendra Talur]

On Thu, Nov 10, 2016 at 7:12 AM, Pranith Kumar Karampuri
 wrote:
> hi,
>   The only problem left was EC taking more time. This should affect
> small files a lot more. Best way to solve it is using compound-fops. So for
> now I think going ahead with the release is best.
>
> We are waiting for Raghavendra Talur's http://review.gluster.org/#/c/15778
> before going ahead with the release. If we missed any other crucial patch
> please let us know.

This patch is now merged.

>
> Will make the release as soon as this patch is merged.
>
> --
> Pranith & Aravinda
>
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Pranith Kumar Karampuri]

On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee  wrote:

>
>
> On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>> I am trying to understand the criticality of these patches. Raghavendra's
>> patch is crucial because gfapi workloads(for samba and qemu) are affected
>> severely. I waited for Krutika's patch because VM usecase can lead to disk
>> corruption on replace-brick. If you could let us know the criticality and
>> we are in agreement that they are this severe, we can definitely take them
>> in. Otherwise next release is better IMO. Thoughts?
>>
>
> If you are asking about how critical they are, then the first two are
> definitely not but third one is actually a critical one as if user upgrades
> from 3.6 to latest with quota enable, further peer probes get rejected and
> the only work around is to disable quota and re-enable it back.
>
> On a different note, 3.9 head is not static and moving forward. So if you
> are really looking at only critical patches need to go in, that's not
> happening, just a word of caution!
>

Yes this is one more workflow problem. There is no way to stop others from
merging it in the tool. I once screwed Kaushal's release process by merging
a patch because I didn't see his mail about pausing merges or something. I
will send out a post-mortem about our experiences and the painpoints we
felt after 3.9.0 release.


>
>
>> On Thu, Nov 10, 2016 at 12:56 PM, Atin Mukherjee 
>> wrote:
>>
>>> Pranith,
>>>
>>> I'd like to see following patches getting in:
>>>
>>> http://review.gluster.org/#/c/15722/
>>> http://review.gluster.org/#/c/15714/
>>> http://review.gluster.org/#/c/15792/
>>>
>>
>>>
>>>
>>>
>>> On Thu, Nov 10, 2016 at 7:12 AM, Pranith Kumar Karampuri <
>>> pkara...@redhat.com> wrote:
>>>
 hi,
   The only problem left was EC taking more time. This should affect
 small files a lot more. Best way to solve it is using compound-fops. So for
 now I think going ahead with the release is best.

 We are waiting for Raghavendra Talur's http://review.gluster.org/#/c/
 15778 before going ahead with the release. If we missed any other
 crucial patch please let us know.

 Will make the release as soon as this patch is merged.

 --
 Pranith & Aravinda

 ___
 maintainers mailing list
 maintain...@gluster.org
 http://www.gluster.org/mailman/listinfo/maintainers


>>>
>>>
>>> --
>>>
>>> ~ Atin (atinm)
>>>
>>
>>
>>
>> --
>> Pranith
>>
>
>
>
> --
>
> ~ Atin (atinm)
>



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

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Pranith Kumar Karampuri]

On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee  wrote:

>
>
> On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>> I am trying to understand the criticality of these patches. Raghavendra's
>> patch is crucial because gfapi workloads(for samba and qemu) are affected
>> severely. I waited for Krutika's patch because VM usecase can lead to disk
>> corruption on replace-brick. If you could let us know the criticality and
>> we are in agreement that they are this severe, we can definitely take them
>> in. Otherwise next release is better IMO. Thoughts?
>>
>
> If you are asking about how critical they are, then the first two are
> definitely not but third one is actually a critical one as if user upgrades
> from 3.6 to latest with quota enable, further peer probes get rejected and
> the only work around is to disable quota and re-enable it back.
>

Let me take Raghavendra G's input also here.

Raghavendra, what do you think we should do? Merge it or live with it till
3.9.1?


>
> On a different note, 3.9 head is not static and moving forward. So if you
> are really looking at only critical patches need to go in, that's not
> happening, just a word of caution!
>
>
>> On Thu, Nov 10, 2016 at 12:56 PM, Atin Mukherjee 
>> wrote:
>>
>>> Pranith,
>>>
>>> I'd like to see following patches getting in:
>>>
>>> http://review.gluster.org/#/c/15722/
>>> http://review.gluster.org/#/c/15714/
>>> http://review.gluster.org/#/c/15792/
>>>
>>
>>>
>>>
>>>
>>> On Thu, Nov 10, 2016 at 7:12 AM, Pranith Kumar Karampuri <
>>> pkara...@redhat.com> wrote:
>>>
 hi,
   The only problem left was EC taking more time. This should affect
 small files a lot more. Best way to solve it is using compound-fops. So for
 now I think going ahead with the release is best.

 We are waiting for Raghavendra Talur's http://review.gluster.org/#/c/
 15778 before going ahead with the release. If we missed any other
 crucial patch please let us know.

 Will make the release as soon as this patch is merged.

 --
 Pranith & Aravinda

 ___
 maintainers mailing list
 maintain...@gluster.org
 http://www.gluster.org/mailman/listinfo/maintainers


>>>
>>>
>>> --
>>>
>>> ~ Atin (atinm)
>>>
>>
>>
>>
>> --
>> Pranith
>>
>
>
>
> --
>
> ~ Atin (atinm)
>



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

[Gluster-devel] Glusto Status Update

[Nigel Babu]

Hello folks,

Shwetha and I have gotten far enough to get the Glusto tests to pass for Fuse
mounts, NFS, and Samba. Well the fix for Samba isn't in yet, but we know what
we need to do. Thanks to help from Kaushal, Shyam, Nithya, Jiffin, and
Raghavendra Talur.

Shwetha is also working on documentation for the libraries so we can write
tests for 3.10. At this point, it we need to figure out how to leverage Glusto.

Here's what I think we should do:
* We already produce nightly builds on Centos CI. We're going to be running
  tests against these nightly builds with Glusto.

* After the tests pass, let's sign the packages, and copy them to
  downloads.gluster.org. This means we will have tested nightly builds.

* In the future, when we want to run test days, we should be running it against
  packages that have been tested with automation.

* Pranith, I remember, worked on check lists for this release. Now would be the
  time for component owners to figure out which of those check list items can
  be converted to automated tests by 3.10. What can make your life easier if
  you wrote automated tests for it?

* From this release's test day, if you can think of something that would be
  useful to automate, that's also useful.

If you're excited to start writing tests and are stuck, here are the people to 
contact:
* Glusto - Jonathan.
* Glustolibs-gluster and glustolibs-io - Shwetha, Arty, and Apeksha.
* Issues with the tests results on Centos CI or test setup - Nigel.

Things we know are bad and needs to improve:
* Documentation for libraries. Shwetha and Jonathan are already working on
  this. As a workaround, I recommend reading the glustolibs-gluster and
  glustolibs-io code. The code itself is well documented.
* It doesn't actually pass yet. Yes, we know. Almost all the problems have been
  identified. We're working on reviewing the code and landing it.

If you have questions or concerns, please let us know on this thread.

--
nigelb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] FSFE pads to github wiki / alternative etherpad - info. required

[Saravanakumar Arumugam]

Hi,

I am working on moving fsfe pages  to github wiki( as discussed in 
Gluster community meeting, yesterday).

Identified the following links present in fsfe etherpad.

I need your help to check whether the link(maybe created by you) needs 
to be moved to github wiki.

Also, if any other link you wish to add.

Note:
Only items which will "not change" will be moved to github wiki.
(example - meeting status, meeting template)

Items which needs to be updated(read realtime colloboration) will NOT be 
moved to github wiki.

(example - bugs to triage updated real time by multiple users).
We need to identify alternative "etherpad" for the same.

Now the links:
=
https://public.pad.fsfe.org/p/gluster-bug-triage

https://public.pad.fsfe.org/p/gluster-bugs-to-triage

https://public.pad.fsfe.org/p/gluster-community-meetings

https://public.pad.fsfe.org/p/gluster-3.7-hangouts

https://public.pad.fsfe.org/p/glusterfs-release-process-201606

https://public.pad.fsfe.org/p/glusterfs-compound-fops

https://public.pad.fsfe.org/p/glusterfs-3.8-release-notes

https://public.pad.fsfe.org/p/gluster-spurious-failures

https://public.pad.fsfe.org/p/gluster-automated-bug-workflow

https://public.pad.fsfe.org/p/gluster-3.8-features

https://public.pad.fsfe.org/p/gluster-login-issues

https://public.pad.fsfe.org/p/dht_lookup_optimize

https://public.pad.fsfe.org/p/gluster-gerrit-migration

https://public.pad.fsfe.org/p/gluster-component-release-checklist

https://public.pad.fsfe.org/p/glusterfs-bitrot-notes

https://public.pad.fsfe.org/p/review-for-glusterfs-3.7

https://public.pad.fsfe.org/p/gluster-xattr-categorization

https://public.pad.fsfe.org/p/Snapshots_in_glusterfs

https://public.pad.fsfe.org/p/gluster-gd2-kaushal

https://public.pad.fsfe.org/p/gluster-events

https://public.pad.fsfe.org/p/gluster-slogans

https://public.pad.fsfe.org/p/gluster-weekly-news

https://public.pad.fsfe.org/p/gluster-next-planning

https://public.pad.fsfe.org/p/gluster-heketi
==


Thanks,
Saravanakumar




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

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Raghavendra G]

On Thu, Nov 10, 2016 at 2:14 PM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

>
>
> On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee 
> wrote:
>
>>
>>
>> On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
>> pkara...@redhat.com> wrote:
>>
>>> I am trying to understand the criticality of these patches.
>>> Raghavendra's patch is crucial because gfapi workloads(for samba and qemu)
>>> are affected severely. I waited for Krutika's patch because VM usecase can
>>> lead to disk corruption on replace-brick. If you could let us know the
>>> criticality and we are in agreement that they are this severe, we can
>>> definitely take them in. Otherwise next release is better IMO. Thoughts?
>>>
>>
>> If you are asking about how critical they are, then the first two are
>> definitely not but third one is actually a critical one as if user upgrades
>> from 3.6 to latest with quota enable, further peer probes get rejected and
>> the only work around is to disable quota and re-enable it back.
>>
>
> Let me take Raghavendra G's input also here.
>
> Raghavendra, what do you think we should do? Merge it or live with it till
> 3.9.1?
>

The commit says quota.conf is rewritten to compatible version during three
operations:
1. enable/disable quota
2. limit usage
3. remove quota limit

I checked the code and it works as stated in commit msg. Probably we can
list the above three operations as work around and take this patch in for
3.9.1


>
>>
>> On a different note, 3.9 head is not static and moving forward. So if you
>> are really looking at only critical patches need to go in, that's not
>> happening, just a word of caution!
>>
>>
>>> On Thu, Nov 10, 2016 at 12:56 PM, Atin Mukherjee 
>>> wrote:
>>>
 Pranith,

 I'd like to see following patches getting in:

 http://review.gluster.org/#/c/15722/
 http://review.gluster.org/#/c/15714/
 http://review.gluster.org/#/c/15792/

>>>



 On Thu, Nov 10, 2016 at 7:12 AM, Pranith Kumar Karampuri <
 pkara...@redhat.com> wrote:

> hi,
>   The only problem left was EC taking more time. This should
> affect small files a lot more. Best way to solve it is using 
> compound-fops.
> So for now I think going ahead with the release is best.
>
> We are waiting for Raghavendra Talur's http://review.gluster.org/#/c/
> 15778 before going ahead with the release. If we missed any other
> crucial patch please let us know.
>
> Will make the release as soon as this patch is merged.
>
> --
> Pranith & Aravinda
>
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers
>
>


 --

 ~ Atin (atinm)

>>>
>>>
>>>
>>> --
>>> Pranith
>>>
>>
>>
>>
>> --
>>
>> ~ Atin (atinm)
>>
>
>
>
> --
> Pranith
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Pranith Kumar Karampuri]

On Thu, Nov 10, 2016 at 7:43 PM, Raghavendra G 
wrote:

>
>
> On Thu, Nov 10, 2016 at 2:14 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>>
>>
>> On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee 
>> wrote:
>>
>>>
>>>
>>> On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
>>> pkara...@redhat.com> wrote:
>>>
 I am trying to understand the criticality of these patches.
 Raghavendra's patch is crucial because gfapi workloads(for samba and qemu)
 are affected severely. I waited for Krutika's patch because VM usecase can
 lead to disk corruption on replace-brick. If you could let us know the
 criticality and we are in agreement that they are this severe, we can
 definitely take them in. Otherwise next release is better IMO. Thoughts?

>>>
>>> If you are asking about how critical they are, then the first two are
>>> definitely not but third one is actually a critical one as if user upgrades
>>> from 3.6 to latest with quota enable, further peer probes get rejected and
>>> the only work around is to disable quota and re-enable it back.
>>>
>>
>> Let me take Raghavendra G's input also here.
>>
>> Raghavendra, what do you think we should do? Merge it or live with it
>> till 3.9.1?
>>
>
> The commit says quota.conf is rewritten to compatible version during three
> operations:
> 1. enable/disable quota
>

This will involve crawling the whole FS doesn't it?

2. limit usage
>

This is a good way IMO. Could Sanoj/you confirm that this works once by
testing it.


> 3. remove quota limit
>

I guess you added this for completeness. We can't really suggest this to
users as a work around.


>
> I checked the code and it works as stated in commit msg. Probably we can
> list the above three operations as work around and take this patch in for
> 3.9.1
>

>
>>
>>>
>>> On a different note, 3.9 head is not static and moving forward. So if
>>> you are really looking at only critical patches need to go in, that's not
>>> happening, just a word of caution!
>>>
>>>
 On Thu, Nov 10, 2016 at 12:56 PM, Atin Mukherjee 
 wrote:

> Pranith,
>
> I'd like to see following patches getting in:
>
> http://review.gluster.org/#/c/15722/
> http://review.gluster.org/#/c/15714/
> http://review.gluster.org/#/c/15792/
>

>
>
>
> On Thu, Nov 10, 2016 at 7:12 AM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>> hi,
>>   The only problem left was EC taking more time. This should
>> affect small files a lot more. Best way to solve it is using 
>> compound-fops.
>> So for now I think going ahead with the release is best.
>>
>> We are waiting for Raghavendra Talur's http://review.gluster.org/#/c/
>> 15778 before going ahead with the release. If we missed any other
>> crucial patch please let us know.
>>
>> Will make the release as soon as this patch is merged.
>>
>> --
>> Pranith & Aravinda
>>
>> ___
>> maintainers mailing list
>> maintain...@gluster.org
>> http://www.gluster.org/mailman/listinfo/maintainers
>>
>>
>
>
> --
>
> ~ Atin (atinm)
>



 --
 Pranith

>>>
>>>
>>>
>>> --
>>>
>>> ~ Atin (atinm)
>>>
>>
>>
>>
>> --
>> Pranith
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Raghavendra G
>



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

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Raghavendra G]

On Thu, Nov 10, 2016 at 8:03 PM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

>
>
> On Thu, Nov 10, 2016 at 7:43 PM, Raghavendra G 
> wrote:
>
>>
>>
>> On Thu, Nov 10, 2016 at 2:14 PM, Pranith Kumar Karampuri <
>> pkara...@redhat.com> wrote:
>>
>>>
>>>
>>> On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee 
>>> wrote:
>>>


 On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
 pkara...@redhat.com> wrote:

> I am trying to understand the criticality of these patches.
> Raghavendra's patch is crucial because gfapi workloads(for samba and qemu)
> are affected severely. I waited for Krutika's patch because VM usecase can
> lead to disk corruption on replace-brick. If you could let us know the
> criticality and we are in agreement that they are this severe, we can
> definitely take them in. Otherwise next release is better IMO. Thoughts?
>

 If you are asking about how critical they are, then the first two are
 definitely not but third one is actually a critical one as if user upgrades
 from 3.6 to latest with quota enable, further peer probes get rejected and
 the only work around is to disable quota and re-enable it back.

>>>
>>> Let me take Raghavendra G's input also here.
>>>
>>> Raghavendra, what do you think we should do? Merge it or live with it
>>> till 3.9.1?
>>>
>>
>> The commit says quota.conf is rewritten to compatible version during
>> three operations:
>> 1. enable/disable quota
>>
>
> This will involve crawling the whole FS doesn't it?
>

Yes. As you suggested, this is not the best work around.


>
> 2. limit usage
>>
>
> This is a good way IMO. Could Sanoj/you confirm that this works once by
> testing it.
>

We can do that by sometime tomorrow afternoon.


>
>> 3. remove quota limit
>>
>
> I guess you added this for completeness. We can't really suggest this to
> users as a work around.
>

Yes. I mentioned it for completeness sake.


>
>
>>
>> I checked the code and it works as stated in commit msg. Probably we can
>> list the above three operations as work around and take this patch in for
>> 3.9.1
>>
>
>>
>>>

 On a different note, 3.9 head is not static and moving forward. So if
 you are really looking at only critical patches need to go in, that's not
 happening, just a word of caution!


> On Thu, Nov 10, 2016 at 12:56 PM, Atin Mukherjee 
> wrote:
>
>> Pranith,
>>
>> I'd like to see following patches getting in:
>>
>> http://review.gluster.org/#/c/15722/
>> http://review.gluster.org/#/c/15714/
>> http://review.gluster.org/#/c/15792/
>>
>
>>
>>
>>
>> On Thu, Nov 10, 2016 at 7:12 AM, Pranith Kumar Karampuri <
>> pkara...@redhat.com> wrote:
>>
>>> hi,
>>>   The only problem left was EC taking more time. This should
>>> affect small files a lot more. Best way to solve it is using 
>>> compound-fops.
>>> So for now I think going ahead with the release is best.
>>>
>>> We are waiting for Raghavendra Talur's
>>> http://review.gluster.org/#/c/15778 before going ahead with the
>>> release. If we missed any other crucial patch please let us know.
>>>
>>> Will make the release as soon as this patch is merged.
>>>
>>> --
>>> Pranith & Aravinda
>>>
>>> ___
>>> maintainers mailing list
>>> maintain...@gluster.org
>>> http://www.gluster.org/mailman/listinfo/maintainers
>>>
>>>
>>
>>
>> --
>>
>> ~ Atin (atinm)
>>
>
>
>
> --
> Pranith
>



 --

 ~ Atin (atinm)

>>>
>>>
>>>
>>> --
>>> Pranith
>>>
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>>
>> --
>> Raghavendra G
>>
>
>
>
> --
> Pranith
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Manikandan Selvaganesh]

Enabling/disabling quota or removing limits are the ways in which
quota.conf is regenerated to the later version. It works properly. And as
Pranith said, both enabling/disabling takes a lot of time to crawl(though
now much faster with enhanced quota enable/disable process) which we cannot
suggest the users with a lot of quota configuration. Resetting the limit
using limit-usage does not work properly. I have tested the same. The
workaround is based on the user setup here. I mean the steps he exactly
used in order matters here. The workaround is not so generic. However,
quota enable/disable would regenerate the file on any case.

IMO, this bug is critical. I am not sure though how often users would hit
this - Updating from 3.6 to latest versions. From 3.7 to latest, its fine,
this has nothing to do with this patch.

On Nov 10, 2016 8:03 PM, "Pranith Kumar Karampuri" 
wrote:

>
>
> On Thu, Nov 10, 2016 at 7:43 PM, Raghavendra G 
> wrote:
>
>>
>>
>> On Thu, Nov 10, 2016 at 2:14 PM, Pranith Kumar Karampuri <
>> pkara...@redhat.com> wrote:
>>
>>>
>>>
>>> On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee 
>>> wrote:
>>>


 On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
 pkara...@redhat.com> wrote:

> I am trying to understand the criticality of these patches.
> Raghavendra's patch is crucial because gfapi workloads(for samba and qemu)
> are affected severely. I waited for Krutika's patch because VM usecase can
> lead to disk corruption on replace-brick. If you could let us know the
> criticality and we are in agreement that they are this severe, we can
> definitely take them in. Otherwise next release is better IMO. Thoughts?
>

 If you are asking about how critical they are, then the first two are
 definitely not but third one is actually a critical one as if user upgrades
 from 3.6 to latest with quota enable, further peer probes get rejected and
 the only work around is to disable quota and re-enable it back.

>>>
>>> Let me take Raghavendra G's input also here.
>>>
>>> Raghavendra, what do you think we should do? Merge it or live with it
>>> till 3.9.1?
>>>
>>
>> The commit says quota.conf is rewritten to compatible version during
>> three operations:
>> 1. enable/disable quota
>>
>
> This will involve crawling the whole FS doesn't it?
>
> 2. limit usage
>>
>
> This is a good way IMO. Could Sanoj/you confirm that this works once by
> testing it.
>
>
>> 3. remove quota limit
>>
>
> I guess you added this for completeness. We can't really suggest this to
> users as a work around.
>
>
>>
>> I checked the code and it works as stated in commit msg. Probably we can
>> list the above three operations as work around and take this patch in for
>> 3.9.1
>>
>
>>
>>>

 On a different note, 3.9 head is not static and moving forward. So if
 you are really looking at only critical patches need to go in, that's not
 happening, just a word of caution!


> On Thu, Nov 10, 2016 at 12:56 PM, Atin Mukherjee 
> wrote:
>
>> Pranith,
>>
>> I'd like to see following patches getting in:
>>
>> http://review.gluster.org/#/c/15722/
>> http://review.gluster.org/#/c/15714/
>> http://review.gluster.org/#/c/15792/
>>
>
>>
>>
>>
>> On Thu, Nov 10, 2016 at 7:12 AM, Pranith Kumar Karampuri <
>> pkara...@redhat.com> wrote:
>>
>>> hi,
>>>   The only problem left was EC taking more time. This should
>>> affect small files a lot more. Best way to solve it is using 
>>> compound-fops.
>>> So for now I think going ahead with the release is best.
>>>
>>> We are waiting for Raghavendra Talur's
>>> http://review.gluster.org/#/c/15778 before going ahead with the
>>> release. If we missed any other crucial patch please let us know.
>>>
>>> Will make the release as soon as this patch is merged.
>>>
>>> --
>>> Pranith & Aravinda
>>>
>>> ___
>>> maintainers mailing list
>>> maintain...@gluster.org
>>> http://www.gluster.org/mailman/listinfo/maintainers
>>>
>>>
>>
>>
>> --
>>
>> ~ Atin (atinm)
>>
>
>
>
> --
> Pranith
>



 --

 ~ Atin (atinm)

>>>
>>>
>>>
>>> --
>>> Pranith
>>>
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>>
>> --
>> Raghavendra G
>>
>
>
>
> --
> Pranith
>
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers
>
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Vijay Bellur]

On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
 wrote:
> Enabling/disabling quota or removing limits are the ways in which quota.conf
> is regenerated to the later version. It works properly. And as Pranith said,
> both enabling/disabling takes a lot of time to crawl(though now much faster
> with enhanced quota enable/disable process) which we cannot suggest the
> users with a lot of quota configuration. Resetting the limit using
> limit-usage does not work properly. I have tested the same. The workaround
> is based on the user setup here. I mean the steps he exactly used in order
> matters here. The workaround is not so generic. However, quota
> enable/disable would regenerate the file on any case.
>
> IMO, this bug is critical. I am not sure though how often users would hit
> this - Updating from 3.6 to latest versions. From 3.7 to latest, its fine,
> this has nothing to do with this patch.
>

Given that we are done with the last release in 3.6.x, I think there
would be users looking to upgrade.  My vote is to include the
necessary patches in 3.9 and not let users go through unnatural
workflows to get quota working again in 3.9.0.

Thanks,
Vijay
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Feedback on DHT option "cluster.readdir-optimize"

[Vijay Bellur]

On Thu, Nov 10, 2016 at 3:17 AM, Nithya Balachandran
 wrote:
>
>
> On 8 November 2016 at 20:21, Kyle Johnson  wrote:
>>
>> Hey there,
>>
>> We have a number of processes which daily walk our entire directory tree
>> and perform operations on the found files.
>>
>> Pre-gluster, this processes was able to complete within 24 hours of
>> starting.  After outgrowing that single server and moving to a gluster setup
>> (two bricks, two servers, distribute, 10gig uplink), the processes became
>> unusable.
>>
>> After turning this option on, we were back to normal run times, with the
>> process completing within 24 hours.
>>
>> Our data is heavy nested in a large number of subfolders under /media/ftp.
>
>
> Thanks for getting back to us - this is very good information. Can you
> provide a few more details?
>
> How deep is your directory tree and roughly how many directories do you have
> at each level?
> Are all your files in the lowest level dirs or do they exist on several
> levels?
> Would you be willing to provide the gluster volume info output for this
> volume?
>>


I have had performance improvement with this option when the first
level below the root consisted several thousands of directories
without any files. IIRC, I was testing this in a 16 x 2 setup.

Regards,
Vijay
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Raghavendra G]

On Thu, Nov 10, 2016 at 8:46 PM, Manikandan Selvaganesh <
manikandancs...@gmail.com> wrote:

> Enabling/disabling quota or removing limits are the ways in which
> quota.conf is regenerated to the later version. It works properly. And as
> Pranith said, both enabling/disabling takes a lot of time to crawl(though
> now much faster with enhanced quota enable/disable process) which we cannot
> suggest the users with a lot of quota configuration. Resetting the limit
> using limit-usage does not work properly. I have tested the same. The
> workaround is based on the user setup here. I mean the steps he exactly
> used in order matters here. The workaround is not so generic.
>

Thanks Manikandan for the reply :). I've not tested this, but went through
the code. If I am not wrong, function glusterd_store_quota_config  would
write a quota.conf which is compatible for versions >= 3.7. This function
is invoked by glusterd_quota_limit_usage unconditionally in success path.
What am I missing here?

@Pranith,

Since Manikandan says his tests didn't succeed always, probably we should
do any of the following
1. hold back the release till we successfully test limit-usage to rewrite
quota.conf (I can do this tomorrow)
2. get the patch in question for 3.9
3. If 1 is failing, debug why 1 is not working and fix that.

regards,
Raghavendra

> However, quota enable/disable would regenerate the file on any case.
>
> IMO, this bug is critical. I am not sure though how often users would hit
> this - Updating from 3.6 to latest versions. From 3.7 to latest, its fine,
> this has nothing to do with this patch.
>
> On Nov 10, 2016 8:03 PM, "Pranith Kumar Karampuri" 
> wrote:
>
>>
>>
>> On Thu, Nov 10, 2016 at 7:43 PM, Raghavendra G 
>> wrote:
>>
>>>
>>>
>>> On Thu, Nov 10, 2016 at 2:14 PM, Pranith Kumar Karampuri <
>>> pkara...@redhat.com> wrote:
>>>


 On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee 
 wrote:

>
>
> On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>> I am trying to understand the criticality of these patches.
>> Raghavendra's patch is crucial because gfapi workloads(for samba and 
>> qemu)
>> are affected severely. I waited for Krutika's patch because VM usecase 
>> can
>> lead to disk corruption on replace-brick. If you could let us know the
>> criticality and we are in agreement that they are this severe, we can
>> definitely take them in. Otherwise next release is better IMO. Thoughts?
>>
>
> If you are asking about how critical they are, then the first two are
> definitely not but third one is actually a critical one as if user 
> upgrades
> from 3.6 to latest with quota enable, further peer probes get rejected and
> the only work around is to disable quota and re-enable it back.
>

 Let me take Raghavendra G's input also here.

 Raghavendra, what do you think we should do? Merge it or live with it
 till 3.9.1?

>>>
>>> The commit says quota.conf is rewritten to compatible version during
>>> three operations:
>>> 1. enable/disable quota
>>>
>>
>> This will involve crawling the whole FS doesn't it?
>>
>> 2. limit usage
>>>
>>
>> This is a good way IMO. Could Sanoj/you confirm that this works once by
>> testing it.
>>
>>
>>> 3. remove quota limit
>>>
>>
>> I guess you added this for completeness. We can't really suggest this to
>> users as a work around.
>>
>>
>>>
>>> I checked the code and it works as stated in commit msg. Probably we can
>>> list the above three operations as work around and take this patch in for
>>> 3.9.1
>>>
>>
>>>

>
> On a different note, 3.9 head is not static and moving forward. So if
> you are really looking at only critical patches need to go in, that's not
> happening, just a word of caution!
>
>
>> On Thu, Nov 10, 2016 at 12:56 PM, Atin Mukherjee > > wrote:
>>
>>> Pranith,
>>>
>>> I'd like to see following patches getting in:
>>>
>>> http://review.gluster.org/#/c/15722/
>>> http://review.gluster.org/#/c/15714/
>>> http://review.gluster.org/#/c/15792/
>>>
>>
>>>
>>>
>>>
>>> On Thu, Nov 10, 2016 at 7:12 AM, Pranith Kumar Karampuri <
>>> pkara...@redhat.com> wrote:
>>>
 hi,
   The only problem left was EC taking more time. This should
 affect small files a lot more. Best way to solve it is using 
 compound-fops.
 So for now I think going ahead with the release is best.

 We are waiting for Raghavendra Talur's
 http://review.gluster.org/#/c/15778 before going ahead with the
 release. If we missed any other crucial patch please let us know.

 Will make the release as soon as this patch is merged.

 --
 Pranith & Aravinda

 ___
 maintainers mailing 

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Raghavendra Talur]

On 10-Nov-2016 20:52, "Vijay Bellur"  wrote:
>
> On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
>  wrote:
> > Enabling/disabling quota or removing limits are the ways in which
quota.conf
> > is regenerated to the later version. It works properly. And as Pranith
said,
> > both enabling/disabling takes a lot of time to crawl(though now much
faster
> > with enhanced quota enable/disable process) which we cannot suggest the
> > users with a lot of quota configuration. Resetting the limit using
> > limit-usage does not work properly. I have tested the same. The
workaround
> > is based on the user setup here. I mean the steps he exactly used in
order
> > matters here. The workaround is not so generic. However, quota
> > enable/disable would regenerate the file on any case.
> >
> > IMO, this bug is critical. I am not sure though how often users would
hit
> > this - Updating from 3.6 to latest versions. From 3.7 to latest, its
fine,
> > this has nothing to do with this patch.
> >
>
> Given that we are done with the last release in 3.6.x, I think there
> would be users looking to upgrade.  My vote is to include the
> necessary patches in 3.9 and not let users go through unnatural
> workflows to get quota working again in 3.9.0.

+1, especially considering this is a ".0" release.

>
> Thanks,
> Vijay
> ___
> maintainers mailing list
> maintain...@gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Feedback on DHT option "cluster.readdir-optimize"

[Raghavendra G]

On Thu, Nov 10, 2016 at 8:57 PM, Vijay Bellur  wrote:

> On Thu, Nov 10, 2016 at 3:17 AM, Nithya Balachandran
>  wrote:
> >
> >
> > On 8 November 2016 at 20:21, Kyle Johnson  wrote:
> >>
> >> Hey there,
> >>
> >> We have a number of processes which daily walk our entire directory tree
> >> and perform operations on the found files.
> >>
> >> Pre-gluster, this processes was able to complete within 24 hours of
> >> starting.  After outgrowing that single server and moving to a gluster
> setup
> >> (two bricks, two servers, distribute, 10gig uplink), the processes
> became
> >> unusable.
> >>
> >> After turning this option on, we were back to normal run times, with the
> >> process completing within 24 hours.
> >>
> >> Our data is heavy nested in a large number of subfolders under
> /media/ftp.
> >
> >
> > Thanks for getting back to us - this is very good information. Can you
> > provide a few more details?
> >
> > How deep is your directory tree and roughly how many directories do you
> have
> > at each level?
> > Are all your files in the lowest level dirs or do they exist on several
> > levels?
> > Would you be willing to provide the gluster volume info output for this
> > volume?
> >>
>
>
> I have had performance improvement with this option when the first
> level below the root consisted several thousands of directories
> without any files. IIRC, I was testing this in a 16 x 2 setup.
>

Yes Vijay. I remember you mentioning it. This option is expected to only
boost readdir performance on a directory containing subdirectories. For
files it has no effect.

On a similar note, I think we can also skip linkto files in readdirp  (on
brick) as dht_readdirp picks the dentry from subvol containing data-file.


> Regards,
> Vijay
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Shyam]

On 11/10/2016 10:21 AM, Vijay Bellur wrote:

On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
 wrote:

Enabling/disabling quota or removing limits are the ways in which quota.conf
is regenerated to the later version. It works properly. And as Pranith said,
both enabling/disabling takes a lot of time to crawl(though now much faster
with enhanced quota enable/disable process) which we cannot suggest the
users with a lot of quota configuration. Resetting the limit using
limit-usage does not work properly. I have tested the same. The workaround
is based on the user setup here. I mean the steps he exactly used in order
matters here. The workaround is not so generic. However, quota
enable/disable would regenerate the file on any case.

IMO, this bug is critical. I am not sure though how often users would hit
this - Updating from 3.6 to latest versions. From 3.7 to latest, its fine,
this has nothing to do with this patch.



Given that we are done with the last release in 3.6.x, I think there
would be users looking to upgrade.  My vote is to include the
necessary patches in 3.9 and not let users go through unnatural
workflows to get quota working again in 3.9.0.




Consider this a curiosity question ATM,

3.9 is an LTM, right? So we are not stating workflows here are set in 
stone? Can this not be an projected workflow?




Thanks,
Vijay
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


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

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Vijay Bellur]

On Thu, Nov 10, 2016 at 10:49 AM, Shyam  wrote:
>
>
> On 11/10/2016 10:21 AM, Vijay Bellur wrote:
>>
>> On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
>>  wrote:
>>>
>>> Enabling/disabling quota or removing limits are the ways in which
>>> quota.conf
>>> is regenerated to the later version. It works properly. And as Pranith
>>> said,
>>> both enabling/disabling takes a lot of time to crawl(though now much
>>> faster
>>> with enhanced quota enable/disable process) which we cannot suggest the
>>> users with a lot of quota configuration. Resetting the limit using
>>> limit-usage does not work properly. I have tested the same. The
>>> workaround
>>> is based on the user setup here. I mean the steps he exactly used in
>>> order
>>> matters here. The workaround is not so generic. However, quota
>>> enable/disable would regenerate the file on any case.
>>>
>>> IMO, this bug is critical. I am not sure though how often users would hit
>>> this - Updating from 3.6 to latest versions. From 3.7 to latest, its
>>> fine,
>>> this has nothing to do with this patch.
>>>
>>
>> Given that we are done with the last release in 3.6.x, I think there
>> would be users looking to upgrade.  My vote is to include the
>> necessary patches in 3.9 and not let users go through unnatural
>> workflows to get quota working again in 3.9.0.
>
>
> 
>
> Consider this a curiosity question ATM,
>
> 3.9 is an LTM, right? So we are not stating workflows here are set in stone?
> Can this not be an projected workflow?
>


3.9 is a STM release as per [1].

Irrespective of a release being LTM or not, being able to upgrade to a
release without operational disruptions is a requirement.

I was referring to the upgrade workflow in my previous email. I seem
to be having a dense moment and am unable to comprehend your question
about workflows. Can you please re-phrase that for me?

Thanks!
Vijay

[1] https://www.gluster.org/community/release-schedule/
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Manikandan Selvaganesh]

Raghavendra,

No problem. As you said , glusterd_quota_limit_usage invokes the function
which regenerates the conf file. Though I do not remember exactly, to my
understanding when I tried, it did not work properly in my setup. It is
apparently because in the later function where we regenerate the quota.conf
for versions greater than or equal to 3.7, when it is setting a limit or
ideally when you are resetting a limit, it searches for the gfid on which
it needs to set/reset the limit and modify only that to 17 bytes leaving
the remaining ones untouched which again would result in unexpected
behavior. In the case of enable or disable, the entire file gets newly
generated. With this patch, we have done that during an upgrade as well.

Even I am not completely sure. Anyways its better to test and confirm the
fact. I can test the same over the weekend if it's fine.

On Nov 10, 2016 9:00 PM, "Raghavendra G"  wrote:

>
>
> On Thu, Nov 10, 2016 at 8:46 PM, Manikandan Selvaganesh <
> manikandancs...@gmail.com> wrote:
>
>> Enabling/disabling quota or removing limits are the ways in which
>> quota.conf is regenerated to the later version. It works properly. And as
>> Pranith said, both enabling/disabling takes a lot of time to crawl(though
>> now much faster with enhanced quota enable/disable process) which we cannot
>> suggest the users with a lot of quota configuration. Resetting the limit
>> using limit-usage does not work properly. I have tested the same. The
>> workaround is based on the user setup here. I mean the steps he exactly
>> used in order matters here. The workaround is not so generic.
>>
>
> Thanks Manikandan for the reply :). I've not tested this, but went through
> the code. If I am not wrong, function glusterd_store_quota_config  would
> write a quota.conf which is compatible for versions >= 3.7. This function
> is invoked by glusterd_quota_limit_usage unconditionally in success path.
> What am I missing here?
>
> @Pranith,
>
> Since Manikandan says his tests didn't succeed always, probably we should
> do any of the following
> 1. hold back the release till we successfully test limit-usage to rewrite
> quota.conf (I can do this tomorrow)
> 2. get the patch in question for 3.9
> 3. If 1 is failing, debug why 1 is not working and fix that.
>
> regards,
> Raghavendra
>
>> However, quota enable/disable would regenerate the file on any case.
>>
>> IMO, this bug is critical. I am not sure though how often users would hit
>> this - Updating from 3.6 to latest versions. From 3.7 to latest, its fine,
>> this has nothing to do with this patch.
>>
>> On Nov 10, 2016 8:03 PM, "Pranith Kumar Karampuri" 
>> wrote:
>>
>>>
>>>
>>> On Thu, Nov 10, 2016 at 7:43 PM, Raghavendra G 
>>> wrote:
>>>


 On Thu, Nov 10, 2016 at 2:14 PM, Pranith Kumar Karampuri <
 pkara...@redhat.com> wrote:

>
>
> On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee 
> wrote:
>
>>
>>
>> On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
>> pkara...@redhat.com> wrote:
>>
>>> I am trying to understand the criticality of these patches.
>>> Raghavendra's patch is crucial because gfapi workloads(for samba and 
>>> qemu)
>>> are affected severely. I waited for Krutika's patch because VM usecase 
>>> can
>>> lead to disk corruption on replace-brick. If you could let us know the
>>> criticality and we are in agreement that they are this severe, we can
>>> definitely take them in. Otherwise next release is better IMO. Thoughts?
>>>
>>
>> If you are asking about how critical they are, then the first two are
>> definitely not but third one is actually a critical one as if user 
>> upgrades
>> from 3.6 to latest with quota enable, further peer probes get rejected 
>> and
>> the only work around is to disable quota and re-enable it back.
>>
>
> Let me take Raghavendra G's input also here.
>
> Raghavendra, what do you think we should do? Merge it or live with it
> till 3.9.1?
>

 The commit says quota.conf is rewritten to compatible version during
 three operations:
 1. enable/disable quota

>>>
>>> This will involve crawling the whole FS doesn't it?
>>>
>>> 2. limit usage

>>>
>>> This is a good way IMO. Could Sanoj/you confirm that this works once by
>>> testing it.
>>>
>>>
 3. remove quota limit

>>>
>>> I guess you added this for completeness. We can't really suggest this to
>>> users as a work around.
>>>
>>>

 I checked the code and it works as stated in commit msg. Probably we
 can list the above three operations as work around and take this patch in
 for 3.9.1

>>>

>
>>
>> On a different note, 3.9 head is not static and moving forward. So if
>> you are really looking at only critical patches need to go in, that's not
>> happening, just a word of caution!
>>
>>
>>> On Thu, Nov 10, 2016 at 12:56 PM, Atin Muk

Re: [Gluster-devel] Restructuring download.gluster.org package directories (WAS: Missing Debian packages)

[Vijay Bellur]

On Wed, Oct 19, 2016 at 3:56 AM, Niels de Vos  wrote:
> On Tue, Oct 18, 2016 at 02:05:55PM -0400, Vijay Bellur wrote:
>> On Tue, Oct 18, 2016 at 1:59 PM, Joe Julian  wrote:
>> > On 10/18/2016 09:52 AM, Shane StClair wrote:
>> >
>> > Yes, I'm well aware that packages are built by volunteers. Right now
>> > Gluster's Debian repos are breaking apt updates for anyone using these
>> > repos, all of which previously worked:
>> >
>> > https://download.gluster.org/pub/gluster/glusterfs/3.7/LATEST/
>> > https://download.gluster.org/pub/gluster/glusterfs/3.8/LATEST/Debian/
>> > https://download.gluster.org/pub/gluster/glusterfs/LATEST/Debian/
>> >
>> > I'm trying to alert the volunteer(s) to this situation
>> >
>> >
>> > +1
>> >
>> > And I asked him to email here since those volunteers are on this list and I
>> > don't know who they are for certain. I know there was a bulk of vacations
>> > last week so I suspected it might be related, but I didn't know for sure.
>> > It's worthy of a poke just to make sure it wasn't some sort of error or
>> > oversight.
>> >
>> >
>> > since I assume the intent is to not break systems, and to advise that 
>> > Debian
>> > users be directed to not use LATEST URLs if this is the new normal.
>> >
>>
>> Can we change the directory structure from /LATEST/
>> to //LATEST? Doing it that way will provide
>> volunteers the liberty to change LATEST for a distro after the related
>> packages are uploaded.
>
> Yes, I think that would be good.
>
> The current/old /LATEST/ can then become a symlink to
> the //LATEST so that we dont break it for everyone.
>
> Kaleb is doing most (if not all!) packaging that pops up on
> download.gluster.org. Nigel and Misc showed some interest in helping
> out, and maybe the can start with creating this new structure?
>

Bumping up this thread as we have not reached a conclusion.

Misc/Nigel - would you be able to help with the restructuring
described in this thread?

Thanks,
Vijay
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Shyam]

On 11/10/2016 11:01 AM, Vijay Bellur wrote:

On Thu, Nov 10, 2016 at 10:49 AM, Shyam  wrote:



On 11/10/2016 10:21 AM, Vijay Bellur wrote:


On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
 wrote:
Given that we are done with the last release in 3.6.x, I think there
would be users looking to upgrade.  My vote is to include the
necessary patches in 3.9 and not let users go through unnatural
workflows to get quota working again in 3.9.0.





Consider this a curiosity question ATM,

3.9 is an LTM, right? So we are not stating workflows here are set in stone?
Can this not be an projected workflow?




3.9 is a STM release as per [1].


Sorry, I meant STM.



Irrespective of a release being LTM or not, being able to upgrade to a
release without operational disruptions is a requirement.


I would say upgrade to an STM *maybe* painful, as it is an STM and hence 
may contain changes that are yet to be announced stable or changed 
workflows that are not easy to upgrade to. We do need to document them 
though, even for the STM.


Along these lines, the next LTM should be as stated, i.e "without 
operational disruptions". The STM is for adventurous folks, no?




I was referring to the upgrade workflow in my previous email. I seem
to be having a dense moment and am unable to comprehend your question
about workflows. Can you please re-phrase that for me?


No, I guess there were a few confusing remarks in my response. I hope 
additional responses above make this more clear or at least intent that 
I see with an STM more clear.




Thanks!
Vijay

[1] https://www.gluster.org/community/release-schedule/


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

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Vijay Bellur]

On Thu, Nov 10, 2016 at 11:14 AM, Shyam  wrote:
> On 11/10/2016 11:01 AM, Vijay Bellur wrote:
>>
>> On Thu, Nov 10, 2016 at 10:49 AM, Shyam  wrote:
>>>
>>>
>>>
>>> On 11/10/2016 10:21 AM, Vijay Bellur wrote:


 On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
  wrote:
 Given that we are done with the last release in 3.6.x, I think there
 would be users looking to upgrade.  My vote is to include the
 necessary patches in 3.9 and not let users go through unnatural
 workflows to get quota working again in 3.9.0.
>>>
>>>
>>>
>>> 
>>>
>>> Consider this a curiosity question ATM,
>>>
>>> 3.9 is an LTM, right? So we are not stating workflows here are set in
>>> stone?
>>> Can this not be an projected workflow?
>>>
>>
>>
>> 3.9 is a STM release as per [1].
>
>
> Sorry, I meant STM.
>
>>
>> Irrespective of a release being LTM or not, being able to upgrade to a
>> release without operational disruptions is a requirement.
>
>
> I would say upgrade to an STM *maybe* painful, as it is an STM and hence may
> contain changes that are yet to be announced stable or changed workflows
> that are not easy to upgrade to. We do need to document them though, even
> for the STM.
>
> Along these lines, the next LTM should be as stated, i.e "without
> operational disruptions". The STM is for adventurous folks, no?
>

In my view STM releases for getting new features out early. This would
enable early adopters to try and provide feedback about new features.
Existing features and upgrades should work smoothly. IOW, we do not
want to have known regressions for existing features in STM releases.
New features might have rough edges and this should be amply
advertised.

In this specific case, quota has not undergone any significant changes
in 3.9 and letting such a relatively unchanged feature affect users
upgrading from 3.6 does not seem right to me. Also note that since
LATEST in d.g.o would point to 3.9.0 after the release, users
performing package upgrades on their systems could end up with 3.9.0
inadvertently.

-Vijay
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Niels de Vos]

On Thu, Nov 10, 2016 at 11:44:21AM -0500, Vijay Bellur wrote:
> On Thu, Nov 10, 2016 at 11:14 AM, Shyam  wrote:
> > On 11/10/2016 11:01 AM, Vijay Bellur wrote:
> >>
> >> On Thu, Nov 10, 2016 at 10:49 AM, Shyam  wrote:
> >>>
> >>>
> >>>
> >>> On 11/10/2016 10:21 AM, Vijay Bellur wrote:
> 
> 
>  On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
>   wrote:
>  Given that we are done with the last release in 3.6.x, I think there
>  would be users looking to upgrade.  My vote is to include the
>  necessary patches in 3.9 and not let users go through unnatural
>  workflows to get quota working again in 3.9.0.
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>> Consider this a curiosity question ATM,
> >>>
> >>> 3.9 is an LTM, right? So we are not stating workflows here are set in
> >>> stone?
> >>> Can this not be an projected workflow?
> >>>
> >>
> >>
> >> 3.9 is a STM release as per [1].
> >
> >
> > Sorry, I meant STM.
> >
> >>
> >> Irrespective of a release being LTM or not, being able to upgrade to a
> >> release without operational disruptions is a requirement.
> >
> >
> > I would say upgrade to an STM *maybe* painful, as it is an STM and hence may
> > contain changes that are yet to be announced stable or changed workflows
> > that are not easy to upgrade to. We do need to document them though, even
> > for the STM.
> >
> > Along these lines, the next LTM should be as stated, i.e "without
> > operational disruptions". The STM is for adventurous folks, no?
> >
> 
> In my view STM releases for getting new features out early. This would
> enable early adopters to try and provide feedback about new features.
> Existing features and upgrades should work smoothly. IOW, we do not
> want to have known regressions for existing features in STM releases.
> New features might have rough edges and this should be amply
> advertised.

I do not think users on 3.6 are the right consumers for a STM release.
These users are conservative and did not ugrade earlier. I doubt they
are interested in new features *now*. Users that did not upgrade before,
are unlikely the users that will upgrade in three months when 3.9 is
EOL.

> In this specific case, quota has not undergone any significant changes
> in 3.9 and letting such a relatively unchanged feature affect users
> upgrading from 3.6 does not seem right to me. Also note that since
> LATEST in d.g.o would point to 3.9.0 after the release, users
> performing package upgrades on their systems could end up with 3.9.0
> inadvertently.

The packages from the CentOS Storage SIG will by default provide the
latest LTM release. The STM release is provided in addition, and needs
an extra step to enable.

I am not sure how we can handle this in other distributions (or also
with the packages on d.g.o.).

Niels


signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Niels de Vos]

On Thu, Nov 10, 2016 at 02:13:32PM +0530, Pranith Kumar Karampuri wrote:
> On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee  wrote:
> 
> >
> >
> > On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
> > pkara...@redhat.com> wrote:
> >
> >> I am trying to understand the criticality of these patches. Raghavendra's
> >> patch is crucial because gfapi workloads(for samba and qemu) are affected
> >> severely. I waited for Krutika's patch because VM usecase can lead to disk
> >> corruption on replace-brick. If you could let us know the criticality and
> >> we are in agreement that they are this severe, we can definitely take them
> >> in. Otherwise next release is better IMO. Thoughts?
> >>
> >
> > If you are asking about how critical they are, then the first two are
> > definitely not but third one is actually a critical one as if user upgrades
> > from 3.6 to latest with quota enable, further peer probes get rejected and
> > the only work around is to disable quota and re-enable it back.
> >
> > On a different note, 3.9 head is not static and moving forward. So if you
> > are really looking at only critical patches need to go in, that's not
> > happening, just a word of caution!
> >
> 
> Yes this is one more workflow problem. There is no way to stop others from
> merging it in the tool. I once screwed Kaushal's release process by merging
> a patch because I didn't see his mail about pausing merges or something. I
> will send out a post-mortem about our experiences and the painpoints we
> felt after 3.9.0 release.

All bugfix updates have defined dates for releases. I expect that all
maintainers are aware of those. At least the maintainers that merge
patches in the stable branches. A couple of days before the release is
planned, patch merging should be coordinated with the release
engineer(s).
  https://www.gluster.org/community/release-schedule/

This is not the case for 3.8 yet, but because it is in RC state, none
but the release engineers are supposed to merge patches. That is what we
followed for other releases, I do not assume it changed.

We should probably document this better, possibly in the maintainers
responsibilities document (which I fail to find atm).

Niels


> 
> 
> >
> >
> >> On Thu, Nov 10, 2016 at 12:56 PM, Atin Mukherjee 
> >> wrote:
> >>
> >>> Pranith,
> >>>
> >>> I'd like to see following patches getting in:
> >>>
> >>> http://review.gluster.org/#/c/15722/
> >>> http://review.gluster.org/#/c/15714/
> >>> http://review.gluster.org/#/c/15792/
> >>>
> >>
> >>>
> >>>
> >>>
> >>> On Thu, Nov 10, 2016 at 7:12 AM, Pranith Kumar Karampuri <
> >>> pkara...@redhat.com> wrote:
> >>>
>  hi,
>    The only problem left was EC taking more time. This should affect
>  small files a lot more. Best way to solve it is using compound-fops. So 
>  for
>  now I think going ahead with the release is best.
> 
>  We are waiting for Raghavendra Talur's http://review.gluster.org/#/c/
>  15778 before going ahead with the release. If we missed any other
>  crucial patch please let us know.
> 
>  Will make the release as soon as this patch is merged.
> 
>  --
>  Pranith & Aravinda
> 
>  ___
>  maintainers mailing list
>  maintain...@gluster.org
>  http://www.gluster.org/mailman/listinfo/maintainers
> 
> 
> >>>
> >>>
> >>> --
> >>>
> >>> ~ Atin (atinm)
> >>>
> >>
> >>
> >>
> >> --
> >> Pranith
> >>
> >
> >
> >
> > --
> >
> > ~ Atin (atinm)
> >
> 
> 
> 
> -- 
> Pranith

> ___
> maintainers mailing list
> maintain...@gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers



signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Shyam]

On 11/10/2016 11:56 AM, Niels de Vos wrote:

On Thu, Nov 10, 2016 at 11:44:21AM -0500, Vijay Bellur wrote:

On Thu, Nov 10, 2016 at 11:14 AM, Shyam  wrote:

On 11/10/2016 11:01 AM, Vijay Bellur wrote:


On Thu, Nov 10, 2016 at 10:49 AM, Shyam  wrote:




On 11/10/2016 10:21 AM, Vijay Bellur wrote:



On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
 wrote:
Given that we are done with the last release in 3.6.x, I think there
would be users looking to upgrade.  My vote is to include the
necessary patches in 3.9 and not let users go through unnatural
workflows to get quota working again in 3.9.0.






Consider this a curiosity question ATM,

3.9 is an LTM, right? So we are not stating workflows here are set in
stone?
Can this not be an projected workflow?




3.9 is a STM release as per [1].



Sorry, I meant STM.



Irrespective of a release being LTM or not, being able to upgrade to a
release without operational disruptions is a requirement.



I would say upgrade to an STM *maybe* painful, as it is an STM and hence may
contain changes that are yet to be announced stable or changed workflows
that are not easy to upgrade to. We do need to document them though, even
for the STM.

Along these lines, the next LTM should be as stated, i.e "without
operational disruptions". The STM is for adventurous folks, no?



In my view STM releases for getting new features out early. This would
enable early adopters to try and provide feedback about new features.
Existing features and upgrades should work smoothly. IOW, we do not
want to have known regressions for existing features in STM releases.
New features might have rough edges and this should be amply
advertised.


I do not think users on 3.6 are the right consumers for a STM release.
These users are conservative and did not ugrade earlier. I doubt they
are interested in new features *now*. Users that did not upgrade before,
are unlikely the users that will upgrade in three months when 3.9 is
EOL.


Valid and useful point.

But, just to be clear, if we introduce a non-backward compatible upgrade 
process (say) for a feature in an STM, we need to smoothen this out by 
the LTM, and not use the STM as the gate that let the upgrade process 
through and accept it as final.





In this specific case, quota has not undergone any significant changes
in 3.9 and letting such a relatively unchanged feature affect users
upgrading from 3.6 does not seem right to me. Also note that since
LATEST in d.g.o would point to 3.9.0 after the release, users
performing package upgrades on their systems could end up with 3.9.0
inadvertently.


The packages from the CentOS Storage SIG will by default provide the
latest LTM release. The STM release is provided in addition, and needs
an extra step to enable.


Perfect! This is along the lines of what I had in mind as well. I.e, the 
LTM is provided as the default, and STM is used *by choice*.




I am not sure how we can handle this in other distributions (or also
with the packages on d.g.o.).

Niels


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

Re: [Gluster-devel] Restructuring download.gluster.org package directories (WAS: Missing Debian packages)

[Nigel Babu]

Short answer: Yes, but not right away.

I discussed this with Kaleb at the summit. I'd like to own packaging
entirely (and automate it), but once I have more time to do so. My primary
concern right now is lack of time.

On Thu, Nov 10, 2016 at 9:33 PM, Vijay Bellur  wrote:

> On Wed, Oct 19, 2016 at 3:56 AM, Niels de Vos  wrote:
> > On Tue, Oct 18, 2016 at 02:05:55PM -0400, Vijay Bellur wrote:
> >> On Tue, Oct 18, 2016 at 1:59 PM, Joe Julian 
> wrote:
> >> > On 10/18/2016 09:52 AM, Shane StClair wrote:
> >> >
> >> > Yes, I'm well aware that packages are built by volunteers. Right now
> >> > Gluster's Debian repos are breaking apt updates for anyone using these
> >> > repos, all of which previously worked:
> >> >
> >> > https://download.gluster.org/pub/gluster/glusterfs/3.7/LATEST/
> >> > https://download.gluster.org/pub/gluster/glusterfs/3.8/LATEST/Debian/
> >> > https://download.gluster.org/pub/gluster/glusterfs/LATEST/Debian/
> >> >
> >> > I'm trying to alert the volunteer(s) to this situation
> >> >
> >> >
> >> > +1
> >> >
> >> > And I asked him to email here since those volunteers are on this list
> and I
> >> > don't know who they are for certain. I know there was a bulk of
> vacations
> >> > last week so I suspected it might be related, but I didn't know for
> sure.
> >> > It's worthy of a poke just to make sure it wasn't some sort of error
> or
> >> > oversight.
> >> >
> >> >
> >> > since I assume the intent is to not break systems, and to advise that
> Debian
> >> > users be directed to not use LATEST URLs if this is the new normal.
> >> >
> >>
> >> Can we change the directory structure from /LATEST/
> >> to //LATEST? Doing it that way will provide
> >> volunteers the liberty to change LATEST for a distro after the related
> >> packages are uploaded.
> >
> > Yes, I think that would be good.
> >
> > The current/old /LATEST/ can then become a symlink to
> > the //LATEST so that we dont break it for everyone.
> >
> > Kaleb is doing most (if not all!) packaging that pops up on
> > download.gluster.org. Nigel and Misc showed some interest in helping
> > out, and maybe the can start with creating this new structure?
> >
>
> Bumping up this thread as we have not reached a conclusion.
>
> Misc/Nigel - would you be able to help with the restructuring
> described in this thread?
>
> Thanks,
> Vijay
>



-- 
nigelb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Sanoj Unnikrishnan]

On Thu, Nov 10, 2016 at 9:33 PM, Manikandan Selvaganesh <
manikandancs...@gmail.com> wrote:

>
> No problem. As you said , glusterd_quota_limit_usage invokes the function
> which regenerates the conf file. Though I do not remember exactly, to my
> understanding when I tried, it did not work properly in my setup. It is
> apparently because in the later function where we regenerate the quota.conf
> for versions greater than or equal to 3.7, when it is setting a limit or
> ideally when you are resetting a limit, it searches for the gfid on which
> it needs to set/reset the limit and modify only that to 17 bytes leaving
> the remaining ones untouched which again would result in unexpected
> behavior. In the case of enable or disable, the entire file gets newly
> generated. With this patch, we have done that during an upgrade as well.
>

 The code seems to handles this. The first thing done (before parsing for
gfid) is to bring the conf to 1.2 version in glusterd_store_quota_config.

Even I am not completely sure. Anyways its better to test and confirm the
> fact. I can test the same over the weekend if it's fine.
>

Ran into an unrelated set up issue at my end while testing this, I Will
test this before noon.

Thanks and Regards,
Sanoj
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Glusto Status Update

[Vijay Bellur]

Thank you for the update. It is exciting to see glusto move ahead! I
will add an agenda item around populating tests in glusto to next
week's maintainers' meeting.

Regards,
Vijay

On Thu, Nov 10, 2016 at 6:52 AM, Nigel Babu  wrote:
> Hello folks,
>
> Shwetha and I have gotten far enough to get the Glusto tests to pass for Fuse
> mounts, NFS, and Samba. Well the fix for Samba isn't in yet, but we know what
> we need to do. Thanks to help from Kaushal, Shyam, Nithya, Jiffin, and
> Raghavendra Talur.
>
> Shwetha is also working on documentation for the libraries so we can write
> tests for 3.10. At this point, it we need to figure out how to leverage 
> Glusto.
>
> Here's what I think we should do:
> * We already produce nightly builds on Centos CI. We're going to be running
>   tests against these nightly builds with Glusto.
>
> * After the tests pass, let's sign the packages, and copy them to
>   downloads.gluster.org. This means we will have tested nightly builds.
>
> * In the future, when we want to run test days, we should be running it 
> against
>   packages that have been tested with automation.
>
> * Pranith, I remember, worked on check lists for this release. Now would be 
> the
>   time for component owners to figure out which of those check list items can
>   be converted to automated tests by 3.10. What can make your life easier if
>   you wrote automated tests for it?
>
> * From this release's test day, if you can think of something that would be
>   useful to automate, that's also useful.
>
> If you're excited to start writing tests and are stuck, here are the people 
> to contact:
> * Glusto - Jonathan.
> * Glustolibs-gluster and glustolibs-io - Shwetha, Arty, and Apeksha.
> * Issues with the tests results on Centos CI or test setup - Nigel.
>
> Things we know are bad and needs to improve:
> * Documentation for libraries. Shwetha and Jonathan are already working on
>   this. As a workaround, I recommend reading the glustolibs-gluster and
>   glustolibs-io code. The code itself is well documented.
> * It doesn't actually pass yet. Yes, we know. Almost all the problems have 
> been
>   identified. We're working on reviewing the code and landing it.
>
> If you have questions or concerns, please let us know on this thread.
>
> --
> nigelb
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Vijay Bellur]

On Thu, Nov 10, 2016 at 11:56 AM, Niels de Vos  wrote:
> On Thu, Nov 10, 2016 at 11:44:21AM -0500, Vijay Bellur wrote:
>> On Thu, Nov 10, 2016 at 11:14 AM, Shyam  wrote:
>> > On 11/10/2016 11:01 AM, Vijay Bellur wrote:
>> >>
>> >> On Thu, Nov 10, 2016 at 10:49 AM, Shyam  wrote:
>> >>>
>> >>>
>> >>>
>> >>> On 11/10/2016 10:21 AM, Vijay Bellur wrote:
>> 
>> 
>>  On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
>>   wrote:
>>  Given that we are done with the last release in 3.6.x, I think there
>>  would be users looking to upgrade.  My vote is to include the
>>  necessary patches in 3.9 and not let users go through unnatural
>>  workflows to get quota working again in 3.9.0.
>> >>>
>> >>>
>> >>>
>> >>> 
>> >>>
>> >>> Consider this a curiosity question ATM,
>> >>>
>> >>> 3.9 is an LTM, right? So we are not stating workflows here are set in
>> >>> stone?
>> >>> Can this not be an projected workflow?
>> >>>
>> >>
>> >>
>> >> 3.9 is a STM release as per [1].
>> >
>> >
>> > Sorry, I meant STM.
>> >
>> >>
>> >> Irrespective of a release being LTM or not, being able to upgrade to a
>> >> release without operational disruptions is a requirement.
>> >
>> >
>> > I would say upgrade to an STM *maybe* painful, as it is an STM and hence 
>> > may
>> > contain changes that are yet to be announced stable or changed workflows
>> > that are not easy to upgrade to. We do need to document them though, even
>> > for the STM.
>> >
>> > Along these lines, the next LTM should be as stated, i.e "without
>> > operational disruptions". The STM is for adventurous folks, no?
>> >
>>
>> In my view STM releases for getting new features out early. This would
>> enable early adopters to try and provide feedback about new features.
>> Existing features and upgrades should work smoothly. IOW, we do not
>> want to have known regressions for existing features in STM releases.
>> New features might have rough edges and this should be amply
>> advertised.
>
> I do not think users on 3.6 are the right consumers for a STM release.
> These users are conservative and did not ugrade earlier. I doubt they
> are interested in new features *now*. Users that did not upgrade before,
> are unlikely the users that will upgrade in three months when 3.9 is
> EOL.
>
>> In this specific case, quota has not undergone any significant changes
>> in 3.9 and letting such a relatively unchanged feature affect users
>> upgrading from 3.6 does not seem right to me. Also note that since
>> LATEST in d.g.o would point to 3.9.0 after the release, users
>> performing package upgrades on their systems could end up with 3.9.0
>> inadvertently.
>
> The packages from the CentOS Storage SIG will by default provide the
> latest LTM release. The STM release is provided in addition, and needs
> an extra step to enable.
>
> I am not sure how we can handle this in other distributions (or also
> with the packages on d.g.o.).

Maybe we should not flip the LATEST for non-RPM distributions in
d.g.o? or should we introduce LTM/LATEST and encourage users to change
their repository files to point to this?

Packaging in distributions would be handled by package maintainers and
I presume they can decide the appropriateness of a release for
packaging?

Thanks,
Vijay
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] getting "Transport endpoint is not connected" in glusterfs mount log file.

[ABHISHEK PALIWAL]

Hi,

Its an urgent case.

Atleast provide your views on this

On Wed, Nov 9, 2016 at 11:08 AM, ABHISHEK PALIWAL 
wrote:

> Hi,
>
> We could see that sync is getting failed to sync the GlusterFS bricks due
> to error trace "Transport endpoint is not connected "
>
> [2016-10-31 04:06:03.627395] E [MSGID: 114031] 
> [client-rpc-fops.c:1673:client3_3_finodelk_cbk]
> 0-c_glusterfs-client-9: remote operation failed [Transport endpoint is not
> connected]
> [2016-10-31 04:06:03.628381] I [socket.c:3308:socket_submit_request]
> 0-c_glusterfs-client-9: not connected (priv->connected = 0)
> [2016-10-31 04:06:03.628432] W [rpc-clnt.c:1586:rpc_clnt_submit]
> 0-c_glusterfs-client-9: failed to submit rpc-request (XID: 0x7f5f Program:
> GlusterFS 3.3, ProgVers: 330, Proc: 30) to rpc-transport
> (c_glusterfs-client-9)
> [2016-10-31 04:06:03.628466] E [MSGID: 114031] 
> [client-rpc-fops.c:1673:client3_3_finodelk_cbk]
> 0-c_glusterfs-client-9: remote operation failed [Transport endpoint is not
> connected]
> [2016-10-31 04:06:03.628475] I [MSGID: 108019] 
> [afr-lk-common.c:1086:afr_lock_blocking]
> 0-c_glusterfs-replicate-0: unable to lock on even one child
> [2016-10-31 04:06:03.628539] I [MSGID: 108019] 
> [afr-transaction.c:1224:afr_post_blocking_inodelk_cbk]
> 0-c_glusterfs-replicate-0: Blocking inodelks failed.
> [2016-10-31 04:06:03.628630] W [fuse-bridge.c:1282:fuse_err_cbk]
> 0-glusterfs-fuse: 20790: FLUSH() ERR => -1 (Transport endpoint is not
> connected)
> [2016-10-31 04:06:03.629149] E [rpc-clnt.c:362:saved_frames_unwind] (-->
> /usr/lib64/libglusterfs.so.0(_gf_log_callingfn-0xb5c80)[0x3fff8ab79f58]
> (--> /usr/lib64/libgfrpc.so.0(saved_frames_unwind-0x1b7a0)[0x3fff8ab1dc90]
> (--> /usr/lib64/libgfrpc.so.0(saved_frames_destroy-0x1b638)[0x3fff8ab1de10]
> (--> 
> /usr/lib64/libgfrpc.so.0(rpc_clnt_connection_cleanup-0x19af8)[0x3fff8ab1fb18]
> (--> /usr/lib64/libgfrpc.so.0(rpc_clnt_notify-0x18e68)[0x3fff8ab20808]
> ) 0-c_glusterfs-client-9: forced unwinding frame type(GlusterFS 3.3)
> op(LOOKUP(27)) called at 2016-10-31 04:06:03.624346 (xid=0x7f5a)
> [2016-10-31 04:06:03.629183] I [rpc-clnt.c:1847:rpc_clnt_reconfig]
> 0-c_glusterfs-client-9: changing port to 49391 (from 0)
> [2016-10-31 04:06:03.629210] W [MSGID: 114031] 
> [client-rpc-fops.c:2971:client3_3_lookup_cbk]
> 0-c_glusterfs-client-9: remote operation failed. Path: /loadmodules_norepl/
> CXC1725605_P93A001/cello/emasviews (b0e5a94e-a432-4dce-b86f-a551555780a2)
> [Transport endpoint is not connected]
>
>
> Could you please tell us the reason why we are getting these trace and how
> to resolve this.
>
> Logs are attached here please share your analysis.
>
> Thanks in advanced
>
> --
> Regards
> Abhishek Paliwal
>



-- 




Regards
Abhishek Paliwal
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Feedback on DHT option "cluster.readdir-optimize"

[Mohammed Rafi K C]

On 11/10/2016 09:05 PM, Raghavendra G wrote:
>
>
> On Thu, Nov 10, 2016 at 8:57 PM, Vijay Bellur  > wrote:
>
> On Thu, Nov 10, 2016 at 3:17 AM, Nithya Balachandran
> mailto:nbala...@redhat.com>> wrote:
> >
> >
> > On 8 November 2016 at 20:21, Kyle Johnson  > wrote:
> >>
> >> Hey there,
> >>
> >> We have a number of processes which daily walk our entire
> directory tree
> >> and perform operations on the found files.
> >>
> >> Pre-gluster, this processes was able to complete within 24 hours of
> >> starting.  After outgrowing that single server and moving to a
> gluster setup
> >> (two bricks, two servers, distribute, 10gig uplink), the
> processes became
> >> unusable.
> >>
> >> After turning this option on, we were back to normal run times,
> with the
> >> process completing within 24 hours.
> >>
> >> Our data is heavy nested in a large number of subfolders under
> /media/ftp.
> >
> >
> > Thanks for getting back to us - this is very good information.
> Can you
> > provide a few more details?
> >
> > How deep is your directory tree and roughly how many directories
> do you have
> > at each level?
> > Are all your files in the lowest level dirs or do they exist on
> several
> > levels?
> > Would you be willing to provide the gluster volume info output
> for this
> > volume?
> >>
>
>
> I have had performance improvement with this option when the first
> level below the root consisted several thousands of directories
> without any files. IIRC, I was testing this in a 16 x 2 setup.
>
>
> Yes Vijay. I remember you mentioning it. This option is expected to
> only boost readdir performance on a directory containing
> subdirectories. For files it has no effect.
>
> On a similar note, I think we can also skip linkto files in readdirp 
> (on brick) as dht_readdirp picks the dentry from subvol containing
> data-file.

doing so will break tier_readdirp.

Rafi KC

>
>
> Regards,
> Vijay
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org 
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 
>
>
>
>
> -- 
> Raghavendra G
>
>
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users

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

Re: [Gluster-devel] [Gluster-users] getting "Transport endpoint is not connected" in glusterfs mount log file.

[Raghavendra Talur]

On 11-Nov-2016 11:50, "Mohammed Rafi K C"  wrote:
>
> Hi Abhishek,
>
> Could you please see if you are bricks are healthy or not, may be you can
do a gluster volume status or you can look into the logs. If bricks are not
running can you please attach the bricks logs in /var/log/gluster/bricks/ .
>
>
> Rafi KC

Also,  please provide details of Gluster version and setup.
>
>
> On 11/11/2016 10:20 AM, ABHISHEK PALIWAL wrote:
>>
>> Hi,
>>
>> Its an urgent case.
>>
>> Atleast provide your views on this
>>
>> On Wed, Nov 9, 2016 at 11:08 AM, ABHISHEK PALIWAL <
abhishpali...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> We could see that sync is getting failed to sync the GlusterFS bricks
due to error trace "Transport endpoint is not connected "
>>>
>>> [2016-10-31 04:06:03.627395] E [MSGID: 114031]
[client-rpc-fops.c:1673:client3_3_finodelk_cbk] 0-c_glusterfs-client-9:
remote operation failed [Transport endpoint is not connected]
>>> [2016-10-31 04:06:03.628381] I [socket.c:3308:socket_submit_request]
0-c_glusterfs-client-9: not connected (priv->connected = 0)
>>> [2016-10-31 04:06:03.628432] W [rpc-clnt.c:1586:rpc_clnt_submit]
0-c_glusterfs-client-9: failed to submit rpc-request (XID: 0x7f5f Program:
GlusterFS 3.3, ProgVers: 330, Proc: 30) to rpc-transport
(c_glusterfs-client-9)
>>> [2016-10-31 04:06:03.628466] E [MSGID: 114031]
[client-rpc-fops.c:1673:client3_3_finodelk_cbk] 0-c_glusterfs-client-9:
remote operation failed [Transport endpoint is not connected]
>>> [2016-10-31 04:06:03.628475] I [MSGID: 108019]
[afr-lk-common.c:1086:afr_lock_blocking] 0-c_glusterfs-replicate-0: unable
to lock on even one child
>>> [2016-10-31 04:06:03.628539] I [MSGID: 108019]
[afr-transaction.c:1224:afr_post_blocking_inodelk_cbk]
0-c_glusterfs-replicate-0: Blocking inodelks failed.
>>> [2016-10-31 04:06:03.628630] W [fuse-bridge.c:1282:fuse_err_cbk]
0-glusterfs-fuse: 20790: FLUSH() ERR => -1 (Transport endpoint is not
connected)
>>> [2016-10-31 04:06:03.629149] E [rpc-clnt.c:362:saved_frames_unwind]
(-->
/usr/lib64/libglusterfs.so.0(_gf_log_callingfn-0xb5c80)[0x3fff8ab79f58]
(--> /usr/lib64/libgfrpc.so.0(saved_frames_unwind-0x1b7a0)[0x3fff8ab1dc90]
(--> /usr/lib64/libgfrpc.so.0(saved_frames_destroy-0x1b638)[0x3fff8ab1de10]
(-->
/usr/lib64/libgfrpc.so.0(rpc_clnt_connection_cleanup-0x19af8)[0x3fff8ab1fb18]
(--> /usr/lib64/libgfrpc.so.0(rpc_clnt_notify-0x18e68)[0x3fff8ab20808]
) 0-c_glusterfs-client-9: forced unwinding frame type(GlusterFS 3.3)
op(LOOKUP(27)) called at 2016-10-31 04:06:03.624346 (xid=0x7f5a)
>>> [2016-10-31 04:06:03.629183] I [rpc-clnt.c:1847:rpc_clnt_reconfig]
0-c_glusterfs-client-9: changing port to 49391 (from 0)
>>> [2016-10-31 04:06:03.629210] W [MSGID: 114031]
[client-rpc-fops.c:2971:client3_3_lookup_cbk] 0-c_glusterfs-client-9:
remote operation failed. Path:
/loadmodules_norepl/CXC1725605_P93A001/cello/emasviews
(b0e5a94e-a432-4dce-b86f-a551555780a2) [Transport endpoint is not connected]
>>>
>>>
>>> Could you please tell us the reason why we are getting these trace and
how to resolve this.
>>>
>>> Logs are attached here please share your analysis.
>>>
>>> Thanks in advanced
>>>
>>> --
>>> Regards
>>> Abhishek Paliwal
>>
>>
>>
>>
>> --
>>
>>
>>
>>
>> Regards
>> Abhishek Paliwal
>>
>>
>> ___ Gluster-users mailing
list gluster-us...@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-users
>
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] getting "Transport endpoint is not connected" in glusterfs mount log file.

[Mohammed Rafi K C]

Hi Abhishek,

Could you please see if you are bricks are healthy or not, may be you
can do a gluster volume status or you can look into the logs. If bricks
are not running can you please attach the bricks logs in
/var/log/gluster/bricks/ .


Rafi KC


On 11/11/2016 10:20 AM, ABHISHEK PALIWAL wrote:
> Hi,
>
> Its an urgent case.
>
> Atleast provide your views on this
>
> On Wed, Nov 9, 2016 at 11:08 AM, ABHISHEK PALIWAL
> mailto:abhishpali...@gmail.com>> wrote:
>
> Hi,
>
> We could see that sync is getting failed to sync the GlusterFS
> bricks due to error trace "Transport endpoint is not connected "
>
> [2016-10-31 04:06:03.627395] E [MSGID: 114031]
> [client-rpc-fops.c:1673:client3_3_finodelk_cbk]
> 0-c_glusterfs-client-9: remote operation failed [Transport
> endpoint is not connected]
> [2016-10-31 04:06:03.628381] I
> [socket.c:3308:socket_submit_request] 0-c_glusterfs-client-9: not
> connected (priv->connected = 0)
> [2016-10-31 04:06:03.628432] W [rpc-clnt.c:1586:rpc_clnt_submit]
> 0-c_glusterfs-client-9: failed to submit rpc-request (XID: 0x7f5f
> Program: GlusterFS 3.3, ProgVers: 330, Proc: 30) to rpc-transport
> (c_glusterfs-client-9)
> [2016-10-31 04:06:03.628466] E [MSGID: 114031]
> [client-rpc-fops.c:1673:client3_3_finodelk_cbk]
> 0-c_glusterfs-client-9: remote operation failed [Transport
> endpoint is not connected]
> [2016-10-31 04:06:03.628475] I [MSGID: 108019]
> [afr-lk-common.c:1086:afr_lock_blocking]
> 0-c_glusterfs-replicate-0: unable to lock on even one child
> [2016-10-31 04:06:03.628539] I [MSGID: 108019]
> [afr-transaction.c:1224:afr_post_blocking_inodelk_cbk]
> 0-c_glusterfs-replicate-0: Blocking inodelks failed.
> [2016-10-31 04:06:03.628630] W [fuse-bridge.c:1282:fuse_err_cbk]
> 0-glusterfs-fuse: 20790: FLUSH() ERR => -1 (Transport endpoint is
> not connected)
> [2016-10-31 04:06:03.629149] E
> [rpc-clnt.c:362:saved_frames_unwind] (-->
> /usr/lib64/libglusterfs.so.0(_gf_log_callingfn-0xb5c80)[0x3fff8ab79f58]
> (-->
> /usr/lib64/libgfrpc.so.0(saved_frames_unwind-0x1b7a0)[0x3fff8ab1dc90]
> (-->
> /usr/lib64/libgfrpc.so.0(saved_frames_destroy-0x1b638)[0x3fff8ab1de10]
> (-->
> 
> /usr/lib64/libgfrpc.so.0(rpc_clnt_connection_cleanup-0x19af8)[0x3fff8ab1fb18]
> (-->
> /usr/lib64/libgfrpc.so.0(rpc_clnt_notify-0x18e68)[0x3fff8ab20808]
> ) 0-c_glusterfs-client-9: forced unwinding frame
> type(GlusterFS 3.3) op(LOOKUP(27)) called at 2016-10-31
> 04:06:03.624346 (xid=0x7f5a)
> [2016-10-31 04:06:03.629183] I [rpc-clnt.c:1847:rpc_clnt_reconfig]
> 0-c_glusterfs-client-9: changing port to 49391 (from 0)
> [2016-10-31 04:06:03.629210] W [MSGID: 114031]
> [client-rpc-fops.c:2971:client3_3_lookup_cbk]
> 0-c_glusterfs-client-9: remote operation failed. Path:
> /loadmodules_norepl/CXC1725605_P93A001/cello/emasviews
> (b0e5a94e-a432-4dce-b86f-a551555780a2) [Transport endpoint is not
> connected]
>
>
> Could you please tell us the reason why we are getting these trace
> and how to resolve this.
>
> Logs are attached here please share your analysis.
>
> Thanks in advanced
>
> -- 
> Regards
> Abhishek Paliwal
>
>
>
>
> -- 
>
>
>
>
> Regards
> Abhishek Paliwal
>
>
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users

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

Re: [Gluster-devel] [Gluster-users] getting "Transport endpoint is not connected" in glusterfs mount log file.

[Pranith Kumar Karampuri]

As per the logs, the mount is not able to connect to both the bricks. Are
the connections fine?

On Fri, Nov 11, 2016 at 10:20 AM, ABHISHEK PALIWAL 
wrote:

> Hi,
>
> Its an urgent case.
>
> Atleast provide your views on this
>
> On Wed, Nov 9, 2016 at 11:08 AM, ABHISHEK PALIWAL  > wrote:
>
>> Hi,
>>
>> We could see that sync is getting failed to sync the GlusterFS bricks due
>> to error trace "Transport endpoint is not connected "
>>
>> [2016-10-31 04:06:03.627395] E [MSGID: 114031]
>> [client-rpc-fops.c:1673:client3_3_finodelk_cbk] 0-c_glusterfs-client-9:
>> remote operation failed [Transport endpoint is not connected]
>> [2016-10-31 04:06:03.628381] I [socket.c:3308:socket_submit_request]
>> 0-c_glusterfs-client-9: not connected (priv->connected = 0)
>> [2016-10-31 04:06:03.628432] W [rpc-clnt.c:1586:rpc_clnt_submit]
>> 0-c_glusterfs-client-9: failed to submit rpc-request (XID: 0x7f5f Program:
>> GlusterFS 3.3, ProgVers: 330, Proc: 30) to rpc-transport
>> (c_glusterfs-client-9)
>> [2016-10-31 04:06:03.628466] E [MSGID: 114031]
>> [client-rpc-fops.c:1673:client3_3_finodelk_cbk] 0-c_glusterfs-client-9:
>> remote operation failed [Transport endpoint is not connected]
>> [2016-10-31 04:06:03.628475] I [MSGID: 108019]
>> [afr-lk-common.c:1086:afr_lock_blocking] 0-c_glusterfs-replicate-0:
>> unable to lock on even one child
>> [2016-10-31 04:06:03.628539] I [MSGID: 108019]
>> [afr-transaction.c:1224:afr_post_blocking_inodelk_cbk]
>> 0-c_glusterfs-replicate-0: Blocking inodelks failed.
>> [2016-10-31 04:06:03.628630] W [fuse-bridge.c:1282:fuse_err_cbk]
>> 0-glusterfs-fuse: 20790: FLUSH() ERR => -1 (Transport endpoint is not
>> connected)
>> [2016-10-31 04:06:03.629149] E [rpc-clnt.c:362:saved_frames_unwind] (-->
>> /usr/lib64/libglusterfs.so.0(_gf_log_callingfn-0xb5c80)[0x3fff8ab79f58]
>> (--> /usr/lib64/libgfrpc.so.0(saved_frames_unwind-0x1b7a0)[0x3fff8ab1dc90]
>> (--> /usr/lib64/libgfrpc.so.0(saved_frames_destroy-0x1b638)[0x3fff8ab1de10]
>> (--> 
>> /usr/lib64/libgfrpc.so.0(rpc_clnt_connection_cleanup-0x19af8)[0x3fff8ab1fb18]
>> (--> /usr/lib64/libgfrpc.so.0(rpc_clnt_notify-0x18e68)[0x3fff8ab20808]
>> ) 0-c_glusterfs-client-9: forced unwinding frame type(GlusterFS 3.3)
>> op(LOOKUP(27)) called at 2016-10-31 04:06:03.624346 (xid=0x7f5a)
>> [2016-10-31 04:06:03.629183] I [rpc-clnt.c:1847:rpc_clnt_reconfig]
>> 0-c_glusterfs-client-9: changing port to 49391 (from 0)
>> [2016-10-31 04:06:03.629210] W [MSGID: 114031]
>> [client-rpc-fops.c:2971:client3_3_lookup_cbk] 0-c_glusterfs-client-9:
>> remote operation failed. Path: 
>> /loadmodules_norepl/CXC1725605_P93A001/cello/emasviews
>> (b0e5a94e-a432-4dce-b86f-a551555780a2) [Transport endpoint is not
>> connected]
>>
>>
>> Could you please tell us the reason why we are getting these trace and
>> how to resolve this.
>>
>> Logs are attached here please share your analysis.
>>
>> Thanks in advanced
>>
>> --
>> Regards
>> Abhishek Paliwal
>>
>
>
>
> --
>
>
>
>
> Regards
> Abhishek Paliwal
>
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>



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

Re: [Gluster-devel] [Gluster-users] getting "Transport endpoint is not connected" in glusterfs mount log file.

[ABHISHEK PALIWAL]

Hi Rafi KC,

I have already attached all the logs in my first mail and I am getting
these logs on 25th board.

You can find the logs at
logs/d/usr/002500_glusterfiles/varlog_glusterfs/brick/


//Abhishek

On Fri, Nov 11, 2016 at 11:50 AM, Mohammed Rafi K C 
wrote:

> Hi Abhishek,
>
> Could you please see if you are bricks are healthy or not, may be you can
> do a gluster volume status or you can look into the logs. If bricks are not
> running can you please attach the bricks logs in /var/log/gluster/bricks/ .
>
>
> Rafi KC
>
> On 11/11/2016 10:20 AM, ABHISHEK PALIWAL wrote:
>
> Hi,
>
> Its an urgent case.
>
> Atleast provide your views on this
>
> On Wed, Nov 9, 2016 at 11:08 AM, ABHISHEK PALIWAL <
> abhishpali...@gmail.com> wrote:
>
>> Hi,
>>
>> We could see that sync is getting failed to sync the GlusterFS bricks due
>> to error trace "Transport endpoint is not connected "
>>
>> [2016-10-31 04:06:03.627395] E [MSGID: 114031]
>> [client-rpc-fops.c:1673:client3_3_finodelk_cbk] 0-c_glusterfs-client-9:
>> remote operation failed [Transport endpoint is not connected]
>> [2016-10-31 04:06:03.628381] I [socket.c:3308:socket_submit_request]
>> 0-c_glusterfs-client-9: not connected (priv->connected = 0)
>> [2016-10-31 04:06:03.628432] W [rpc-clnt.c:1586:rpc_clnt_submit]
>> 0-c_glusterfs-client-9: failed to submit rpc-request (XID: 0x7f5f Program:
>> GlusterFS 3.3, ProgVers: 330, Proc: 30) to rpc-transport
>> (c_glusterfs-client-9)
>> [2016-10-31 04:06:03.628466] E [MSGID: 114031]
>> [client-rpc-fops.c:1673:client3_3_finodelk_cbk] 0-c_glusterfs-client-9:
>> remote operation failed [Transport endpoint is not connected]
>> [2016-10-31 04:06:03.628475] I [MSGID: 108019]
>> [afr-lk-common.c:1086:afr_lock_blocking] 0-c_glusterfs-replicate-0:
>> unable to lock on even one child
>> [2016-10-31 04:06:03.628539] I [MSGID: 108019]
>> [afr-transaction.c:1224:afr_post_blocking_inodelk_cbk]
>> 0-c_glusterfs-replicate-0: Blocking inodelks failed.
>> [2016-10-31 04:06:03.628630] W [fuse-bridge.c:1282:fuse_err_cbk]
>> 0-glusterfs-fuse: 20790: FLUSH() ERR => -1 (Transport endpoint is not
>> connected)
>> [2016-10-31 04:06:03.629149] E [rpc-clnt.c:362:saved_frames_unwind] (-->
>> /usr/lib64/libglusterfs.so.0(_gf_log_callingfn-0xb5c80)[0x3fff8ab79f58]
>> (--> /usr/lib64/libgfrpc.so.0(saved_frames_unwind-0x1b7a0)[0x3fff8ab1dc90]
>> (--> /usr/lib64/libgfrpc.so.0(saved_frames_destroy-0x1b638)[0x3fff8ab1de10]
>> (--> 
>> /usr/lib64/libgfrpc.so.0(rpc_clnt_connection_cleanup-0x19af8)[0x3fff8ab1fb18]
>> (--> /usr/lib64/libgfrpc.so.0(rpc_clnt_notify-0x18e68)[0x3fff8ab20808]
>> ) 0-c_glusterfs-client-9: forced unwinding frame type(GlusterFS 3.3)
>> op(LOOKUP(27)) called at 2016-10-31 04:06:03.624346 (xid=0x7f5a)
>> [2016-10-31 04:06:03.629183] I [rpc-clnt.c:1847:rpc_clnt_reconfig]
>> 0-c_glusterfs-client-9: changing port to 49391 (from 0)
>> [2016-10-31 04:06:03.629210] W [MSGID: 114031]
>> [client-rpc-fops.c:2971:client3_3_lookup_cbk] 0-c_glusterfs-client-9:
>> remote operation failed. Path: 
>> /loadmodules_norepl/CXC1725605_P93A001/cello/emasviews
>> (b0e5a94e-a432-4dce-b86f-a551555780a2) [Transport endpoint is not
>> connected]
>>
>>
>> Could you please tell us the reason why we are getting these trace and
>> how to resolve this.
>>
>> Logs are attached here please share your analysis.
>>
>> Thanks in advanced
>>
>> --
>> Regards
>> Abhishek Paliwal
>>
>
>
>
> --
>
>
>
>
> Regards
> Abhishek Paliwal
>
>
> ___
> Gluster-users mailing 
> listGluster-users@gluster.orghttp://www.gluster.org/mailman/listinfo/gluster-users
>
>
>


-- 




Regards
Abhishek Paliwal
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-Maintainers] Please pause merging patches to 3.9 waiting for just one patch

[Sanoj Unnikrishnan]

 Pasting Testing Logs
==

3.6

[root@dhcp-0-112 rpms]# /sbin/gluster v create v1 $tm1:/export/sdb/br1
volume create: v1: success: please start the volume to access data

[root@dhcp-0-112 rpms]# gluster v start v1
[root@dhcp-0-112 rpms]#
[root@dhcp-0-112 rpms]#  mount -t glusterfs $tm1:v1 /gluster_vols/vol
[root@dhcp-0-112 rpms]# gluster v quota v1 enable
volume quota : success
[root@dhcp-0-112 rpms]#
[root@dhcp-0-112 rpms]# mkdir -p /gluster_vols/vol/dir1;  gluster v quota
v1 limit-usage /dir1 5MB 10
volume quota : success
[root@dhcp-0-112 rpms]# mkdir -p /gluster_vols/vol/dir2;  gluster v quota
v1 limit-usage /dir2 16MB 10
volume quota : success
[root@dhcp-0-112 rpms]# gluster v quota v1 list
  Path   Hard-limit Soft-limit   Used
Available  Soft-limit exceeded? Hard-limit exceeded?
---
/dir1  5.0MB   10%  0Bytes
5.0MB  No   No
/dir2 16.0MB   10%  0Bytes
16.0MB  No   No
[root@dhcp-0-112 rpms]#
[root@dhcp-0-112 rpms]#
[root@dhcp-0-112 rpms]# rpm -qa | grep glusterfs-ser
glusterfs-server-3.6.9-0.1.gitcaccd6c.fc24.x86_64

[root@dhcp-0-112 rpms]# umount /gluster_vols/vol
[root@dhcp-0-112 rpms]#

[root@dhcp-0-112 rpms]# cat /var/lib/glusterd/vols/v1/quota.conf
[root@dhcp-0-112 rpms]# hexdump /var/lib/glusterd/vols/v1/quota.conf

[root@dhcp-0-112 rpms]# hexdump -c /var/lib/glusterd/vols/v1/quota.conf
000   G   l   u   s   t   e   r   F   S   Q   u   o   t   a
010   c   o   n   f   |   v   e   r   s   i   o   n   :
020   v   1   .   1  \n   U  \t 213   I 252 251   C 337 262   x  \b
030   i   y   r   5 021 312 335   w 366   X   5   B   H 210 260 227
040   ^ 251   X 237   G
045
[root@dhcp-0-112 rpms]#

[root@dhcp-0-112 rpms]# getfattr -d -m. -e hex /export/sdb/br1/dir1/ | grep
gfid
getfattr: Removing leading '/' from absolute path names
trusted.gfid=0x55098b49aaa943dfb278086979723511
[root@dhcp-0-112 rpms]# getfattr -d -m. -e hex /export/sdb/br1/dir2/ | grep
gfid
getfattr: Removing leading '/' from absolute path names
trusted.gfid=0xcadd77f65835424888b0975ea9589f47

[root@dhcp-0-112 rpms]# gluster v stop v1
Stopping volume will make its data inaccessible. Do you want to continue?
(y/n) y
volume stop: v1: success

[root@dhcp-0-112 rpms]# pkill glusterd

+++ Replace with 3.9 build  without patch++

[root@dhcp-0-112 3.9]# systemctl start glusterd
[root@dhcp-0-112 3.9]#
[root@dhcp-0-112 3.9]# rpm -qa | grep glusterfs-ser
glusterfs-server-3.9.0rc2-0.13.gita3bade0.fc24.x86_64
[
[root@dhcp-0-112 3.9]# gluster v set all cluster.op-version 30700
volume set: success

[root@dhcp-0-112 3.9]# gluster v start v1
volume start: v1: success

[root@dhcp-0-112 3.9]#  mount -t glusterfs $tm1:v1 /gluster_vols/vol

>> not sure why we see this , second attempt succeeds
[root@dhcp-0-112 3.9]#  gluster v quota v1 limit-usage /dir1 12MB 10
quota command failed : Failed to start aux mount
[root@dhcp-0-112 3.9]#
[root@dhcp-0-112 3.9]#  gluster v quota v1 limit-usage /dir2 12MB 10
volume quota : success

[root@dhcp-0-112 3.9]# hexdump -c /var/lib/glusterd/vols/v1/quota.conf
000   G   l   u   s   t   e   r   F   S   Q   u   o   t   a
010   c   o   n   f   |   v   e   r   s   i   o   n   :
020   v   1   .   2  \n   U  \t 213   I 252 251   C 337 262   x  \b
030   i   y   r   5 021 001 312 335   w 366   X   5   B   H 210 260
040 227   ^ 251   X 237   G 001
047
[root@dhcp-0-112 3.9]# gluster v quota v1 list
  Path   Hard-limit  Soft-limit  Used
Available  Soft-limit exceeded? Hard-limit exceeded?
---
/dir1  5.0MB 10%(512.0KB)
0Bytes   5.0MB  No   No
/dir2 12.0MB 10%(1.2MB)   0Bytes
12.0MB  No   No
[root@dhcp-0-112 3.9]#
[root@dhcp-0-112 3.9]#  gluster v quota v1 limit-usage /dir1 12MB 10

[root@dhcp-0-112 3.9]# cksum /var/lib/glusterd/vols/v1/quota.conf
496616948 71 /var/lib/glusterd/vols/v1/quota.conf
[root@dhcp-0-112 3.9]#

>> Now we disable , followed by enable and set the same limits to check if
we get the same quota.conf contents

[root@dhcp-0-112 3.9]# /sbin/gluster v quota v1 disable
Disabling quota will delete all the quota configuration. Do you want to
continue? (y/n) y
quota command failed : Volume quota failed. The cluster is operating at
version 30700. Quota command disable is unavailable in this version.
[root@dhcp-0-112 3.9]#

>> we need to upgrade to 3_7_12 to use disable

[root@dhcp-0-112 3.9]# gluster v set all cluster.op-version 30712
v

Re: [Gluster-devel] [Gluster-users] getting "Transport endpoint is not connected" in glusterfs mount log file.

[ABHISHEK PALIWAL]

Hi Pranith,

Could you please tell tell me the logs showing that the mount is not
available to connect to both the bricks.

On Fri, Nov 11, 2016 at 12:05 PM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

> As per the logs, the mount is not able to connect to both the bricks. Are
> the connections fine?
>
> On Fri, Nov 11, 2016 at 10:20 AM, ABHISHEK PALIWAL <
> abhishpali...@gmail.com> wrote:
>
>> Hi,
>>
>> Its an urgent case.
>>
>> Atleast provide your views on this
>>
>> On Wed, Nov 9, 2016 at 11:08 AM, ABHISHEK PALIWAL <
>> abhishpali...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> We could see that sync is getting failed to sync the GlusterFS bricks
>>> due to error trace "Transport endpoint is not connected "
>>>
>>> [2016-10-31 04:06:03.627395] E [MSGID: 114031]
>>> [client-rpc-fops.c:1673:client3_3_finodelk_cbk] 0-c_glusterfs-client-9:
>>> remote operation failed [Transport endpoint is not connected]
>>> [2016-10-31 04:06:03.628381] I [socket.c:3308:socket_submit_request]
>>> 0-c_glusterfs-client-9: not connected (priv->connected = 0)
>>> [2016-10-31 04:06:03.628432] W [rpc-clnt.c:1586:rpc_clnt_submit]
>>> 0-c_glusterfs-client-9: failed to submit rpc-request (XID: 0x7f5f Program:
>>> GlusterFS 3.3, ProgVers: 330, Proc: 30) to rpc-transport
>>> (c_glusterfs-client-9)
>>> [2016-10-31 04:06:03.628466] E [MSGID: 114031]
>>> [client-rpc-fops.c:1673:client3_3_finodelk_cbk] 0-c_glusterfs-client-9:
>>> remote operation failed [Transport endpoint is not connected]
>>> [2016-10-31 04:06:03.628475] I [MSGID: 108019]
>>> [afr-lk-common.c:1086:afr_lock_blocking] 0-c_glusterfs-replicate-0:
>>> unable to lock on even one child
>>> [2016-10-31 04:06:03.628539] I [MSGID: 108019]
>>> [afr-transaction.c:1224:afr_post_blocking_inodelk_cbk]
>>> 0-c_glusterfs-replicate-0: Blocking inodelks failed.
>>> [2016-10-31 04:06:03.628630] W [fuse-bridge.c:1282:fuse_err_cbk]
>>> 0-glusterfs-fuse: 20790: FLUSH() ERR => -1 (Transport endpoint is not
>>> connected)
>>> [2016-10-31 04:06:03.629149] E [rpc-clnt.c:362:saved_frames_unwind]
>>> (--> /usr/lib64/libglusterfs.so.0(_gf_log_callingfn-0xb5c80)[0x3fff8ab79f58]
>>> (--> /usr/lib64/libgfrpc.so.0(saved_frames_unwind-0x1b7a0)[0x3fff8ab1dc90]
>>> (--> /usr/lib64/libgfrpc.so.0(saved_frames_destroy-0x1b638)[0x3fff8ab1de10]
>>> (--> 
>>> /usr/lib64/libgfrpc.so.0(rpc_clnt_connection_cleanup-0x19af8)[0x3fff8ab1fb18]
>>> (--> /usr/lib64/libgfrpc.so.0(rpc_clnt_notify-0x18e68)[0x3fff8ab20808]
>>> ) 0-c_glusterfs-client-9: forced unwinding frame type(GlusterFS 3.3)
>>> op(LOOKUP(27)) called at 2016-10-31 04:06:03.624346 (xid=0x7f5a)
>>> [2016-10-31 04:06:03.629183] I [rpc-clnt.c:1847:rpc_clnt_reconfig]
>>> 0-c_glusterfs-client-9: changing port to 49391 (from 0)
>>> [2016-10-31 04:06:03.629210] W [MSGID: 114031]
>>> [client-rpc-fops.c:2971:client3_3_lookup_cbk] 0-c_glusterfs-client-9:
>>> remote operation failed. Path: 
>>> /loadmodules_norepl/CXC1725605_P93A001/cello/emasviews
>>> (b0e5a94e-a432-4dce-b86f-a551555780a2) [Transport endpoint is not
>>> connected]
>>>
>>>
>>> Could you please tell us the reason why we are getting these trace and
>>> how to resolve this.
>>>
>>> Logs are attached here please share your analysis.
>>>
>>> Thanks in advanced
>>>
>>> --
>>> Regards
>>> Abhishek Paliwal
>>>
>>
>>
>>
>> --
>>
>>
>>
>>
>> Regards
>> Abhishek Paliwal
>>
>> ___
>> Gluster-users mailing list
>> gluster-us...@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-users
>>
>
>
>
> --
> Pranith
>



-- 




Regards
Abhishek Paliwal
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel