[LU-651] Strange error message "is it ok to have flags 0x... and 0x... in the same brw?" Created: 31/Aug/11 Updated: 08/Apr/12 Resolved: 12/Dec/11 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.0.0, Lustre 2.1.0 |
| Fix Version/s: | Lustre 2.2.0, Lustre 2.1.2 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Aurelien Degremont (Inactive) | Assignee: | Zhenyu Xu |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Severity: | 3 |
| Rank (Obsolete): | 4830 |
| Description |
|
We often face the very weird message "is it ok to have flags 0x... and 0x... in the same brw?". This message has no meaning for any Lustre administrators, only for Lustre developpers. |
| Comments |
| Comment by Johann Lombardi (Inactive) [ 31/Aug/11 ] |
|
There are some flags which should not be mixed in the same BRW. Could you please give us some samples of the flag mismatch you see in the logs? |
| Comment by Aurelien Degremont (Inactive) [ 31/Aug/11 ] |
|
We always have "0x520" and "0x420". |
| Comment by Peter Jones [ 31/Aug/11 ] |
|
Bobijam Could you please comment on this one? Thanks Peter |
| Comment by Zhenyu Xu [ 31/Aug/11 ] |
|
I think we need lower this message level. |
| Comment by Zhenyu Xu [ 02/Sep/11 ] |
|
patch tracking at http://review.whamcloud.com/1328 |
| Comment by Peter Jones [ 21/Nov/11 ] |
|
Question asked by Oleg on gerrit "Well, are we sure we only want to print this warning once. I mean then the visibility of it is greatly reduced if it happpens, and it should not happen even once, so if it does happen we want to know and people to report it." |
| Comment by Oleg Drokin [ 21/Nov/11 ] |
|
Bobi, can you please go and see if these particular flags could in fact be mixed and if so, just update the safe mask in can_merge_pages? |
| Comment by Zhenyu Xu [ 21/Nov/11 ] |
|
0x100 is OBD_BRW_NOQUOTA, and from filter_commitrw_write() comment /* if one page is a write-back page from client cache and
* not from direct_io, or it's written by root, then mark
* the whole io request as ignore quota request, remote
* client can not break through quota. */
if (exp_connect_rmtclient(exp))
flags &= ~OBD_BRW_NOQUOTA;
if ((flags & OBD_BRW_NOQUOTA) ||
(flags & (OBD_BRW_FROM_GRANT | OBD_BRW_SYNC)) ==
OBD_BRW_FROM_GRANT)
iobuf->dr_ignore_quota = 1;
so adjacent pages disaccording with OBD_BRW_NOQUOTA flag can not be merged. |
| Comment by Oleg Drokin [ 21/Nov/11 ] |
|
Then this needs to be fixed properly so that such pages are not attempted to be merged |
| Comment by Christopher Morrone [ 21/Nov/11 ] |
|
As I commented in the gerrit ticket, even if we want a message of some kind, the current message is not acceptable. Asking a question "is this ok?" on the console is NOT ok. We need to make a clear statement that an admin will be able to handle. Perhaps something like:
|
| Comment by Christopher Morrone [ 01/Dec/11 ] |
|
How bad is the quota accounting going to get with the http://review.whamcloud.com/1328 patch? Is it roughly comparable? Is it going to be noticeably worse? |
| Comment by Niu Yawei (Inactive) [ 06/Dec/11 ] |
The OBD_BRW_NOQUOTA is applied to the pages written by superuser who can ignore quota limits, but this patch only changes error messages, so it doesn't affect the quota accounting. |
| Comment by Oleg Drokin [ 06/Dec/11 ] |
|
Right, the patch does not change the accounting. I wonder if current code leads to incorrect quota accounting anyway? For the case of both root and some user writing to the same file, depending on who got the first offset, the entire BRW will be quota-enforced (based on the first page flags) and potentially root's write might be lost OR not quota-enforced and then user's write that should fail will not fail. Is this really ok? |
| Comment by Niu Yawei (Inactive) [ 06/Dec/11 ] |
Our currenty implementaion is that the whole BRW request will ignore quota if it has one ignore quota page, so if there is a page is from root or from cached write (cached data has to be written back not matter if it'll exceed quota), the whole BRW request will bypass quota enforcement, so root's write will not be lost but normal user's write could exceed quota limit in such case. Whenever server realize some uid/gid has exceeded quota limit, it'll notify the client to enter sync write mode for normal users, that'll decrease the probability of the case you mentioned. |
| Comment by Build Master (Inactive) [ 12/Dec/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Peter Jones [ 12/Dec/11 ] |
|
Landed for 2.2. Please reopen if any more work is still required for this issue |
| Comment by Build Master (Inactive) [ 12/Dec/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 12/Dec/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 12/Dec/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 12/Dec/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 12/Dec/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 12/Dec/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 12/Dec/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 12/Dec/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 12/Dec/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 12/Dec/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 12/Dec/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 12/Dec/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 12/Dec/11 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|
| Comment by Build Master (Inactive) [ 08/Apr/12 ] |
|
Integrated in Result = SUCCESS
|