Description of problem: ----------------------- SMBv1 Seq Reads have regressed on 3.2 bits : 3.1.3 : 623455 kB/sec 3.2 : 541690 kB/sec Regression : 14% Version-Release number of selected component (if applicable): ------------------------------------------------------------- 3.8.4-15 How reproducible: ----------------- Every time. Actual results: --------------- 14% regression on SMBv1 seq writes with io-threads "on" on 3.2 bits. Expected results: ---------------- Regression threshold : 10% Additional info: ---------------- Volume Name: testvol Type: Distribute Volume ID: 35b73a47-bdc7-48b2-81a1-9b66624ae57c Status: Started Snapshot Count: 0 Number of Bricks: 4 Transport-type: tcp Bricks: Brick1: gqas014.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: gqas015.sbu.lab.eng.bos.redhat.com:/bricks/testvol_brick3 Options Reconfigured: network.inode-lru-limit: 90000 performance.md-cache-timeout: 600 performance.cache-invalidation: on performance.cache-samba-metadata: on performance.stat-prefetch: on features.cache-invalidation-timeout: 600 features.cache-invalidation: on client.event-threads: 2 server.event-threads: 2 cluster.lookup-optimize: off performance.client-io-threads: on transport.address-family: inet performance.readdir-ahead: on nfs.disable: off
3.1.3 : 623455 kB/sec 3.2 Defaults : 541690 kB/sec 3.2 io-threads off : 610286.11 kB/sec Switching off io-threads brings back the lost regression.
Is this still an issue? If not can we close this bug?
(In reply to Atin Mukherjee from comment #14) > Is this still an issue? If not can we close this bug? I don't have much data to answer the question. Since the regression might've carried out over to next releases, we may not have seen this between 3.3 and 3.4 regression suites.
In that case, please close it.
Based on comment #16