[LU-7655] To drop write data on OST to help performance benchmark

• Type: Improvement
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.9.0
• Assignee: Jinshan Xiong (Inactive)
• Reporter: Jinshan Xiong (Inactive)

Description

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.

Issue Links

• is related to: LU-8600 sanity test_399:fake write is slower
• is related to: LU-8726 Do fake read page on OST to help read performance benchmarking

Comments

[Jinshan Xiong (Inactive)]

Li Xi: I would rather open a new ticket. Thanks for your work.

[Li Xi (Inactive)]

Can we reopen this ticket, or should I open a new tickeet for the patch of read bypass? http://review.whamcloud.com/21648

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/5164/
Subject: LU-7655 tests: ost fake write for performance testing
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: f003d3eebbad43e7f8371af663e67c6e56bf5d9a

[Gerrit Updater]

Li Xi ([e-mail]) uploaded a new patch: http://review.whamcloud.com/21648
Subject: LU-7655 osd-ldiskfs: bypass read for benchmark
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: c29bca947c01e767638f11eb040ade7ae59cee2e

[Jinshan Xiong (Inactive)]

Hi Li Xi,

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.

[Li Xi (Inactive)]

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.

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.

Do you have any good idea about how to do this?

[Li Xi (Inactive)]

This is a good idea. And we can do this to read too.

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.