https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-7655 Lustre <p>By setting a fail_loc on the OST side, OST_WRITE RPC will only create transaction and update file size if necessary, but the actual data will be dropped. This will be of great help to performance benchmark on client side.</p> LU-7655

To drop write data on OST to help performance benchmark

Improvement Minor Resolved Fixed Jinshan Xiong Jinshan Xiong Tue, 12 Jan 2016 18:12:21 +0000 Thu, 20 Jul 2017 14:02:11 +0000 Tue, 6 Dec 2016 14:50:24 +0000 Lustre 2.9.0 0 8 <p>This is a good idea. And we can do this to read too.</p> <p>When I was tuning the readahead alogirthm, I made a patch which always set the reading page updated on OST side. And in this way, we can get read peformance of over 3GB/s even with only one node.</p> <p>BTW, I am wondering whether we could add some regression tests for performance. Of course, there will be some hardware requirements in the test. It is not likely that the performance regression tests can be done in a virtual machine. But it might be possible at least for some operations if we could provide similar mechanism like this one to provide huge performance with limited hardware. For example, as said, we could get the very high single thread read performance even with only one node.</p> <p>However, it would be a requirement that the regression tests of performance need to be run repeately on the same hardware for comparison. Thus this is different from the existing regression tests of Lustre. But if we could run the performance tests again and again on the same hardware with the same configuration, we could stop the patches that introduce performance problems from being merged in advance. And that might takes much less time than finding out the bad patches after they are already merged.</p> <p>Do you have any good idea about how to do this?</p> <p>Hi Li Xi,</p> <p>Yes, this is a good idea. Actually we've already had a dedicated cluster for performance test. Our target is to make sure that there is no performance regression for each release.</p> <p>Li Xi (lixi@ddn.com) uploaded a new patch: <a href="http://review.whamcloud.com/21648" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/21648</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7655" title="To drop write data on OST to help performance benchmark" class="issue-link" data-issue-key="LU-7655"><del>LU-7655</del></a> osd-ldiskfs: bypass read for benchmark<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: c29bca947c01e767638f11eb040ade7ae59cee2e</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/5164/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5164/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7655" title="To drop write data on OST to help performance benchmark" class="issue-link" data-issue-key="LU-7655"><del>LU-7655</del></a> tests: ost fake write for performance testing<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: f003d3eebbad43e7f8371af663e67c6e56bf5d9a</p> <p>Can we reopen this ticket, or should I open a new tickeet for the patch of read bypass? <a href="http://review.whamcloud.com/21648" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/21648</a></p> <p>Li Xi: I would rather open a new ticket. Thanks for your work.</p> Related LU-8600 LU-8726 Development Rank 1|hzxxxj: Rank (Obsolete) 9223372036854775807