On Tue, Apr 16, 2019 at 10:27 PM Atin Mukherjee <[email protected]> wrote:
> > > On Tue, Apr 16, 2019 at 9:19 PM Atin Mukherjee <[email protected]> > wrote: > >> >> >> On Tue, Apr 16, 2019 at 7:24 PM Shyam Ranganathan <[email protected]> >> wrote: >> >>> Status: Tagging pending >>> >>> Waiting on patches: >>> (Kotresh/Atin) - glusterd: fix loading ctime in client graph logic >>> https://review.gluster.org/c/glusterfs/+/22579 >> >> >> The regression doesn't pass for the mainline patch. I believe master is >> broken now. With latest master sdfs-sanity.t always fail. We either need to >> fix it or mark it as bad test. >> > > commit 3883887427a7f2dc458a9773e05f7c8ce8e62301 (HEAD) > Author: Pranith Kumar K <[email protected]> > Date: Mon Apr 1 11:14:56 2019 +0530 > > features/locks: error-out {inode,entry}lk fops with all-zero lk-owner > > Problem: > Sometimes we find that developers forget to assign lk-owner for an > inodelk/entrylk/lk before writing code to wind these fops. locks > xlator at the moment allows this operation. This leads to multiple > threads in the same client being able to get locks on the inode > because lk-owner is same and transport is same. So isolation > with locks can't be achieved. > > Fix: > Disallow locks with lk-owner zero. > > fixes bz#1624701 > Change-Id: I1c816280cffd150ebb392e3dcd4d21007cdd767f > Signed-off-by: Pranith Kumar K <[email protected]> > > With the above commit sdfs-sanity.t started failing. But when I looked at > the last regression vote at > https://build.gluster.org/job/centos7-regression/5568/consoleFull I saw > it voted back positive but the bell rang when I saw the overall regression > took less than 2 hours and when I opened the regression link I saw the test > actually failed but still this job voted back +1 at gerrit. > > *Deepshika* - *This is a bad CI bug we have now and have to be addressed > at earliest. Please take a look at > https://build.gluster.org/job/centos7-regression/5568/consoleFull > <https://build.gluster.org/job/centos7-regression/5568/consoleFull> and > investigate why the regression vote wasn't negative.* > > Pranith - I request you to investigate on the sdfs-sanity.t failure > because of this patch. > sdfs is supposed to serialize entry fops by doing entrylk, but all the locks are being done with all-zero lk-owner. In essence sdfs doesn't achieve its goal of mutual exclusion when conflicting operations are executed by same client because two locks on same entry with same all-zero-owner will get locks. The patch which lead to sdfs-sanity.t failure treats inodelk/entrylk/lk fops with all-zero lk-owner as Invalid request to prevent these kinds of bugs. So it exposed the bug in sdfs. I sent a fix for sdfs @ https://review.gluster.org/#/c/glusterfs/+/22582 > *@Maintainers - Please open up every regression link to see the actual > status of the job and don't blindly trust on the +1 vote back at gerrit > till this is addressed.* > > As per the policy, I'm going to revert this commit, watch out for the > patch. I request this to be directly pushed with out waiting for the > regression vote as we had done before in such breakage. Amar/Shyam - I > believe you have this permission? > > >> root@a5f81bd447c2:/home/glusterfs# prove -vf tests/basic/sdfs-sanity.t >> tests/basic/sdfs-sanity.t .. >> 1..7 >> ok 1, LINENUM:8 >> ok 2, LINENUM:9 >> ok 3, LINENUM:11 >> ok 4, LINENUM:12 >> ok 5, LINENUM:13 >> ok 6, LINENUM:16 >> mkdir: cannot create directory ‘/mnt/glusterfs/1/coverage’: Invalid >> argument >> stat: cannot stat '/mnt/glusterfs/1/coverage/dir': Invalid argument >> tests/basic/rpc-coverage.sh: line 61: test: ==: unary operator expected >> not ok 7 , LINENUM:20 >> FAILED COMMAND: tests/basic/rpc-coverage.sh /mnt/glusterfs/1 >> Failed 1/7 subtests >> >> Test Summary Report >> ------------------- >> tests/basic/sdfs-sanity.t (Wstat: 0 Tests: 7 Failed: 1) >> Failed test: 7 >> Files=1, Tests=7, 14 wallclock secs ( 0.02 usr 0.00 sys + 0.58 cusr >> 0.67 csys = 1.27 CPU) >> Result: FAIL >> >> >>> >>> Following patches will not be taken in if CentOS regression does not >>> pass by tomorrow morning Eastern TZ, >>> (Pranith/KingLongMee) - cluster-syncop: avoid duplicate unlock of >>> inodelk/entrylk >>> https://review.gluster.org/c/glusterfs/+/22385 >>> (Aravinda) - geo-rep: IPv6 support >>> https://review.gluster.org/c/glusterfs/+/22488 >>> (Aravinda) - geo-rep: fix integer config validation >>> https://review.gluster.org/c/glusterfs/+/22489 >>> >>> Tracker bug status: >>> (Ravi) - Bug 1693155 - Excessive AFR messages from gluster showing in >>> RHGSWA. >>> All patches are merged, but none of the patches adds the "Fixes" >>> keyword, assume this is an oversight and that the bug is fixed in this >>> release. >>> >>> (Atin) - Bug 1698131 - multiple glusterfsd processes being launched for >>> the same brick, causing transport endpoint not connected >>> No work has occurred post logs upload to bug, restart of bircks and >>> possibly glusterd is the existing workaround when the bug is hit. Moving >>> this out of the tracker for 6.1. >>> >>> (Xavi) - Bug 1699917 - I/O error on writes to a disperse volume when >>> replace-brick is executed >>> Very recent bug (15th April), does not seem to have any critical data >>> corruption or service availability issues, planning on not waiting for >>> the fix in 6.1 >>> >>> - Shyam >>> On 4/6/19 4:38 AM, Atin Mukherjee wrote: >>> > Hi Mohit, >>> > >>> > https://review.gluster.org/22495 should get into 6.1 as it’s a >>> > regression. Can you please attach the respective bug to the tracker >>> Ravi >>> > pointed out? >>> > >>> > >>> > On Sat, 6 Apr 2019 at 12:00, Ravishankar N <[email protected] >>> > <mailto:[email protected]>> wrote: >>> > >>> > Tracker bug is https://bugzilla.redhat.com/show_bug.cgi?id=1692394, >>> in >>> > case anyone wants to add blocker bugs. >>> > >>> > >>> > On 05/04/19 8:03 PM, Shyam Ranganathan wrote: >>> > > Hi, >>> > > >>> > > Expected tagging date for release-6.1 is on April, 10th, 2019. >>> > > >>> > > Please ensure required patches are backported and also are >>> passing >>> > > regressions and are appropriately reviewed for easy merging and >>> > tagging >>> > > on the date. >>> > > >>> > > Thanks, >>> > > Shyam >>> > > _______________________________________________ >>> > > Gluster-devel mailing list >>> > > [email protected] <mailto:[email protected]> >>> > > https://lists.gluster.org/mailman/listinfo/gluster-devel >>> > _______________________________________________ >>> > Gluster-devel mailing list >>> > [email protected] <mailto:[email protected]> >>> > https://lists.gluster.org/mailman/listinfo/gluster-devel >>> > >>> > >>> > -- >>> > - Atin (atinm) >>> > >>> > _______________________________________________ >>> > Gluster-devel mailing list >>> > [email protected] >>> > https://lists.gluster.org/mailman/listinfo/gluster-devel >>> > >>> _______________________________________________ >>> Gluster-devel mailing list >>> [email protected] >>> https://lists.gluster.org/mailman/listinfo/gluster-devel >> >> -- Pranith
_______________________________________________ maintainers mailing list [email protected] https://lists.gluster.org/mailman/listinfo/maintainers
