[Gluster-devel] Unable to send patches to release 3.7 branch.
Hi, Usually when a patch is backported to release 3.7 branch it contains the following from the patch already merged in master: Change-Id: Ib878f39814af566b9250cf6b8ed47da0ca5b1128 BUG: 1226120 Signed-off-by: Avra Sengupta Reviewed-on: http://review.gluster.org/10641 Reviewed-by: Rajesh Joseph Tested-by: NetBSD Build System Reviewed-by: Kaushal M While trying to send this patch from release 3.7 branch I am getting the following error from checkpatch.pl which is not letting me send the patch, and this is new because it didn't use to happen earlier. # ./extras/checkpatch.pl 0001-glusterd-snapshot-Return-correct-errno-in-events-of-.patch Use of uninitialized value $gerrit_url in regexp compilation at ./extras/checkpatch.pl line 1958. ERROR: Unrecognized url address: 'http://review.gluster.org/10313' #16: Reviewed-on: http://review.gluster.org/10313 ERROR: Unrecognized email address: 'NetBSD Build System' #19: Tested-by: NetBSD Build System Patch not according to coding guidelines! please fix. total: 2 errors, 0 warnings, 326 lines checked Why is checkpatch unable to reference the gerrit url? Regards, Avra ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Merging GlusterD changes for 3.7.1
Several of the changes have now been merged on master. When the changes have been backported to 3.7, please add them to the etherpad. We'll be looking at it for changes to be merged once the moratorium is removed. On 28-May-2015 12:18, "Krishnan Parthasarathi" wrote: > > > be merged and needs our attention, add them back to the etherpad at the > END! > > Don't forget to add one of us as a reviewer, it helps with some sanity > checks > > I could perform on this data set ;) Feel free to ask if anything is not > > clear. > > Please add a 'keyword' by which you would like to indicate your patch's > primary > component/feature. For e.g, if it's a patch needed for bitrot feature, > then add "bitrot" > with a _space_ after your review URL. Please be consistent with naming. > i.e, don't > add bitrot and Bitrot for different patches. It's perfectly fine to not > add a > 'keyword'. > > Complete example, > > http://review.gluster.org/10936 bitrot > > cheers, > kp > > > ___ > > 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 > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] New regression failure with EC
Oops, I missed the link :P [1] https://bugzilla.redhat.com/show_bug.cgi?id=1225793 On 05/28/2015 11:21 AM, Xavier Hernandez wrote: Thanks Kaushal, I think I've identified the cause. I filed a bug for it [1] and I'm working on the patch. I'll try to upload it as soon as possible. Xavi On 05/28/2015 07:33 AM, Kaushal M wrote: Got a EC test failure ( ./tests/bugs/disperse/bug-1161621.t) on http://build.gluster.org/job/rackspace-regression-2GB-triggered/9628/consoleFull The change being tested was a pure GlusterD change, so this is most likely a (new?) spurious failure. ~kaushal ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] New regression failure with EC
Thanks Kaushal, I think I've identified the cause. I filed a bug for it [1] and I'm working on the patch. I'll try to upload it as soon as possible. Xavi On 05/28/2015 07:33 AM, Kaushal M wrote: Got a EC test failure ( ./tests/bugs/disperse/bug-1161621.t) on http://build.gluster.org/job/rackspace-regression-2GB-triggered/9628/consoleFull The change being tested was a pure GlusterD change, so this is most likely a (new?) spurious failure. ~kaushal ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Regarding the size parameter in readdir(p) fops
Sorry for the late reply, Niels. I tried what you suggested yesterday and yes, like you predicted, the extra entries are getting dropped by fuse-bridge, and the readdir-ahead translator seems to be showing the same behavior. Thanks for the idea. :) -Krutika - Original Message - > From: "Niels de Vos" > To: "Krutika Dhananjay" > Cc: "Gluster Devel" > Sent: Tuesday, May 19, 2015 3:12:20 PM > Subject: Re: [Gluster-devel] Regarding the size parameter in readdir(p) fops > On Tue, May 19, 2015 at 05:12:35AM -0400, Krutika Dhananjay wrote: > > Hi, > > > > The following patch fixes an issue with readdir(p) in shard xlator: > > http://review.gluster.org/#/c/10809/ whose details can be found in the > > commit message. > > > > One side effect of this is that from shard xlator, the size of the dirents > > list returned to the translators above it could be greater than the > > requested size in the wind path (thanks to Pranith for pointing this out > > during the review of this patch), with the worst-case scenario returning > > (2 * requested_size) worth of entries. > > For example, if fuse requests readdirp with 128k as the size, in the worst > > case, 256k worth of entries could be unwound in return. > > How important is it to strictly adhere to this size limit in each iteration > > of readdir(p)? And what are the repercussions of such behavior? > > > > Note: > > I tried my hand at simulating this issue on my volume but I have so far > > been unsuccessful at hitting this test case. > > Creating large number of files on the root of a sharded volume, triggering > > readdirp on it until ".shard" becomes the last entry read in a given > > iteration, winding the next > > readdirp from shard xlator, and then concatenating the results of two > > readdirps into one is proving to be an exercise in futility. > > Therefore, I am asking this question here to know what could happen "in > > theory" in such situations. > How about modifying xlators/mount/fuse/src/fuse-bridge.c and increasing > the size of the readdir(p) argument there? The FUSE kernel side would > not know about the increased size, but the other xlators would request > a bigger size in subsequent readdir(p) FOPs. > I suspect that the additional dentries in readdir(p) get dropped, and > the next getdents() call from the kernel continues are the offset of the > readdir(p) of the last returned dentry. > Niels ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Fix bug-id extraction in compare-bug-version-and-git-branch
On Thu, May 28, 2015 at 11:54:03AM +0530, Kaushal M wrote:
> The bug-id extraction method in the compare-bug-version-and-git-branch
> was buggy. Which lead to some valid changes being marked as invalid.
> [1],[2]
>
> The following snippet was used
> ```
> BUG=$(git show --name-only --format=email | grep -i '^BUG: ' | cut -f2
> -d ' ' | tail -1)
> ```
>
> The problem is with the usage of `cut`, which as used here cannot
> handle multiple whitespace between 'BUG: ' and the ID.
>
> I'll replac `cut` with `awk` which should work better. The snippet now
> looks like
> ```
> BUG=$(git show --name-only --format=email | awk '{IGNORECASE=1}
> /^BUG:/{print $2}' | tail -1)
> ```
> This should work much better.
Looks good to me. Please update or send a pull request for it too. It
would be aweful if the Jenkins job and the archived script get out of
sync:
https://github.com/gluster/glusterfs-patch-acceptance-tests/
Thanks,
Niels
>
> ~kaushal
>
> [1]: https://review.gluster.org/10797
> [2]: https://review.gluster.org/10849
> ___
> 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
