[LU-3266] Regression tests for NRS policies

• Type: Technical task
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.8.0
• Assignee: WC Triage
• Reporter: Jodi Levi (Inactive)

Issue Links

• is related to: LU-6668 Add tests for TBF
• is related to: LU-3558 NRS TBF policy for QoS purposes

Comments

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/9286/
Subject: LU-3266 test: regression tests for nrs policies
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 38b68e47e5e240fd8d394a944737ecdbcf2fb70f

[Sergey Cheremencev]

Hi,

I've added patch http://review.whamcloud.com/#/c/9286/.
Think will be a lot of comments...

[Nikitas Angelinas]

Sergey <[e-mail]> from our team has started working on addressing this ticket.

[Nikitas Angelinas]

Hi,

Andreas, apologies for the long delay, but I have been on a long (hopefully temporary) 'break' from Lustre work during the last few months. I have spoken to our core Lustre team to see who will be handling this, and hopefully other NRS maintenance work, and we will update with this information as soon as we decide on a way forward; I hope that is an acceptable solution, please let me know if not.

[Andreas Dilger]

Nikitas,
any progress on getting some regression tests for NRS? Just some basic tests to run each policy for a few minutes under load would be great.

As it stands, I tried enabling NRS with the ORR policy on my home server (2.4.1) while it was under load and it crashed almost instantly (bug to be filed separately), so I don't think that code is getting enough testing.

[Andreas Dilger]

Instead of tracking the addition of NRS regression tests under LU-3239 (which is a bug and shouldn't be overloaded with this separate task), open this new ticket for the tests and their landing.

There should be a test for each NRS policy type that enables the policy and does some reasonable number of operations using the policy. It shouldn't run for longer than about 5 minutes per policy (independent of the storage speed) so that it doesn't consume an inordinate amount of testing time for each patch. There needs to be both file-per-process and shared-single-file IO from multiple clients to exercise the different policies properly, so sanityn.sh is probably a good place for it.