Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
*The bug got submitted to the system before I could write anything,writing description here,Apologies* : Description of problem: ----------------------- A regression was introduced in the latest Ganesha bits in large file sequential reads. Gluster 3.8.4-2,Ganesha 2.4.0-2 : 2156113.75 kB/sec Gluster 3.8.4-4,Ganesha 2.4.1-1 : 1421350.29 kB/sec Regression : 35% Version-Release number of selected component (if applicable): ------------------------------------------------------------ nfs-ganesha-gluster-2.4.1-1.el7rhgs.x86_64 glusterfs-ganesha-3.8.4-4.el7rhgs.x86_64 How reproducible: ---------------- 100% Steps to Reproduce: ------------------- 1. Create 2*2 volume.Mount via NFS Ganesha vers=4 and vers=3. 2. Run Iozone Seq read workload(iozone -+m <conf file> -C -w -c -e -i 1 -+n -r 64k -s 8g -t 16) 3. Check for regression with older builds. Actual results: --------------- 35% regression on large file reads on latest builds. Expected results: ----------------- Regression within +-10% is acceptable between releases/dev builds. Additional info: ---------------- OS : RHEL 7.3 *Vol Config* : Volume Name: testvol Type: Distributed-Replicate Volume ID: e84889ee-7bed-426f-b187-2b15fb244175 Status: Started Snapshot Count: 0 Number of Bricks: 2 x 2 = 4 Transport-type: tcp Bricks: Brick1: gqas013.sbu.lab.eng.bos.redhat.com:/bricks/testvol_brick0 Brick2: gqas005.sbu.lab.eng.bos.redhat.com:/bricks/testvol_brick1 Brick3: gqas006.sbu.lab.eng.bos.redhat.com:/bricks/testvol_brick2 Brick4: gqas011.sbu.lab.eng.bos.redhat.com:/bricks/testvol_brick3 Options Reconfigured: ganesha.enable: on features.cache-invalidation: on server.allow-insecure: on performance.stat-prefetch: off transport.address-family: inet performance.readdir-ahead: on nfs.disable: on nfs-ganesha: enable cluster.enable-shared-storage: enable
I tried my perf regression tests on latest gluster build on old Ganesha(2.4.0-2),and I could see sequential reads upto 2000 MBps. Looks like the regression was introduced with the Ganesha rebase.
@Frank, Do you have any clue on what patch (which went into 2.4.1) could have caused this regression when compared to 2.4.0 build.
Nothing in the history jumps out at me. Bisecting the releases might help narrow it down.
when possible please collect wireshark dumps of gnfs and nfs-ganesha during the the v3 large file writes. Thanks.
cancel needinfo, wrong bug