[LU-7795] least_qunit should be tunnable

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.5.3
• Fix Version/s: Lustre 2.9.0
• Type: Improvement
• Priority: Minor
• Reporter: Mahmoud Hanafi
• Assignee: Niu Yawei (Inactive)
• Resolution: Fixed

Description

In order to better adjust filesystem performance when using quotas we would like to have a tunable least_qunit option.

Issue Links

• is related to: LU-4139 Significant perforamce issue when use...

Comments

[Peter Jones]

Niu

Could you please comment on this suggestion?

Thanks

Peter

[Andreas Dilger]

Mahmoud, could you please explain a bit on how you want to tune the least_qunit? Do you want to increase it or decrease it, what performance impact do you see today, and how do you expect the tuning of least_qunit to change the performance?

[Mahmoud Hanafi]

We have reports from users that when they exceed their soft quota there is significant performance impact. We had reported this in LU-4139 and was address to some extent, but we would want more controller over qunit allocation in such situations.

[Niu Yawei (Inactive)]

Hi, Mahmoud , according to the numbers in LU-4139, looks the performance is reasonable after the fixing:

Direct I/O
UnderSoftlimit: 383MB/sec
OverSoftlimit: 359MB/sec
Buffered I/O
UnderSoftlimit:316MB.sec
OverSoftlimit: 304MB/sec

Is your proposal to let user set a larger least_qunit so that the performance won't drop even after over soft limit? One thing worth noting is that larger least_qunit means worse limit/grace time accuracy, so we have to do some sort of compromise here. What do you think about?

[Mahmoud Hanafi]

I think there are some IO patterns that are effected by the softquota limit then others. At least that is what our users are reporting. Since most of our quota are 100'sTB and we have large gap between soft and hard quota we are willing to give up limit/grace time accuracy for no lost of performance.

[Niu Yawei (Inactive)]

I see, the requirement makes sense to me, but I don't think tuning the least_qunit is a proper way, because it affects the hard limit as well.

A better way is to add a proc interface to quota master (qmt), and user may turn off the qunit adjustment for soft limit (no qunit adjustment even if soft limit is exceeded) via this interface. Of course, people should be warned that grace time accuracy will be lost when he turns it off.

I can compose a patch if you don't against. Thanks.

[Mahmoud Hanafi]

Are you purposing a per-user setting or global for a filesystem? Turn off qunit adjustment must a admin only function.

[Niu Yawei (Inactive)]

It's global setting, and least qunit is also a global parameter.

[Mahmoud Hanafi]

That sounds like what we would need.

[Gerrit Updater]

Niu Yawei ([e-mail]) uploaded a new patch: http://review.whamcloud.com/18896
Subject: LU-7795 quota: tuneable soft least qunit
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 601fa84017a98450432d5cb3dbdea0cd8b82e056

[Jay Lan (Inactive)]

Can you provide a back port to 2.5.3-fe?
It is not obvious to me how to resolve the conflicts on lprocfs_quota_qpi_vars declaration.

Thanks!

[Niu Yawei (Inactive)]

Here is the port to b2_5_fe: http://review.whamcloud.com/#/c/18976/

[Mahmoud Hanafi]

With this patch when is client sync writes triggered?

[Niu Yawei (Inactive)]

The client sync write will be triggered when approaching/exceeding hard limit, if there is no hard limit, sync write won't be triggered.

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/18896/
Subject: LU-7795 quota: tuneable soft least qunit
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 0cadce268a09a94824b82bc1a61e98963582c423

[Peter Jones]

Landed for 2.9