|
Ruth, could you please post the output of "lfs df" and "lfs df -i" on your filesystem(s). On the OSS nodes, could you please collect "lctl get_param obdfilter.*.tot_granted" to see if this is the actual cause of the ENOSPC errors. Also, how many clients are connected to the filesystem?
One potential workaround is to release some of the grant from the clients using "lctl set_param osc.*.cur_grant_bytes=2M" and then check lctl get_param obdfilter.*.tot_granted" on the OSS nodes again to see if the total grant space has been reduced.
Have you modified the client's maximum RPC size (via lctl set_param osc.*.max_pages_per_rpc=4M, e.g. to have 4MB RPC size), or the ZFS maximum blocksize (via zfs set recordsize=1048576 lustre/lustre-OST0000 or similar)? That will aggravate this problem until the patch from LU-3522 is landed.
|
|
The max_pages_per_rpc value is default of 256, and the zfs recordsize is 128K. We have 3 OSTs on each OSS rather than just one. We have ~6500 clients mounting the file system.
We requested that some of the heavy users clean up, so the FS is at 75% now. Also moved a couple of affected users to the other (ldiskfs) file system.
No messages so far today. I will go ahead and release some grant if you think it's still necessary or beneficial.
I was guessing a combination of the bug + heavy user activity + high fs usage may have triggered this. Our FS usage tends to run high around here.
|
|
Ruth, the cur_grant_bytes command to release grants is something that you can try as a workaround if the -ENOSPC errors are being hit again. It doesn't hurt to run this now, or occasionally, though it may cause a very brief hiccup in IO performance as the grant is released. The main reason this isn't useful to do (much) in advance of the problem is that this command asks clients try to return their grant to the server, but if the server isn't low on space it will just return the grant back to the client.
The real fix for this problem is indeed the LU-2049 patch. The reason you see this problem when LLNL does not is that you have many more clients connected directly to the filesystem (6500 vs 768) and their OSTs are 72TB vs 30TB so they wouldn't hit this until they reach 99% full.
We are working to get the LU-2049 patch landed to resolve this issue permanently.
|
|
thanks, much appreciated. I'll keep an eye on those messages, they have not resumed since the usage went down.
|
|
We are resolving this as a duplicate.
Ruth – if the problem recurs and you need more help please either ask us to reopen this ticket, or open a new one, as you prefer.
Thanks,
~ jfc.
|
|
John,
FYI...We've been hitting this at LLNL the last week or so. I'll note it on LU-2049 as well.
|
|
We are running the workaround to release grant on the clients from the epilog (ie after each job), just to proactively keep that under control. We have not seen enospc errs in logs again, and usage has hit the 80% mark several times since.
|
|
Ruth,
Thanks for letting us know you went down the grant release route. I had noticed that 32 of our 80 OSTs were ~90% full (the others ~ 65%), so I deactivated those 32 fuller OSTs and that seems to have resolved the problem for now.
|
|
Yesterday we had a server go down with this LBUG:
LustreError: 8117:0:(ofd_grant.c:352:ofd_grant_incoming()) fscratch-OST001d: cli 8c1795e2-8806-4e65-5865-4e42489eac9b/ffff8807dee68400 dirty 33554432 pend 0 grant -54657024
LustreError: 8117:0:(ofd_grant.c:354:ofd_grant_incoming()) LBUG
The client side grant release doesn't seem to be taking effect on that node. The values of tot_granted on the server side were increased to ~5x10^12 on that node only, all the other nodes had values ~2x10^12.
This node has gone down several times in the last few weeks, this is the first time we got any log messages before it died. It seems we should also deactivate those OSTs, and increase the priority of upgrading the servers - although it appears a 2.5 upgrade path is not yet available (looking at LU-2049).
But I'm puzzled at why the grant release doesn't work for just that node. All the others have not been re-booted during this time period since we started the workaround.
|
|
It turns out that the grant release does work, even on the problem node, once the grant on the problem server reaches ~4.9T. It decreased to ~4.0T over the course of a day before the lbug on 2 different targets. The other servers respond to grant release at levels of as low as 1.4T. The usage levels are similar, all osts between 75-80%. The only difference I can find is that the other zpools last item in history is activation of compression back in march. So this one server was rebooted after that compression activation, all the rest were not. Wondering if the size computation is affected by whether compression is on or off? All zpools are reporting 1.03-1.05 ratios.
|
|
FYI: I don't have an exact version for 2.5.4-11chaos (12chaos and 4chaos are tagged in our system, so I have a good idea).
Do you have any logging leading up to the LBUG, by any chance?
|
|
There is nothing prior to the lbug. Here are the traces.
The ofd code at least does not differ between 11chaos and 12chaos versions afaics.
|
|
after deactivating the osts on that node, the rate of increase is slower, but it still is much larger than all the others and not decreasing so far at about ~3.7T.
|
|
Each of the osts have shown a couple of decreases, in the 3.8-3.9 T range.
|
|
Nearly all OSS nodes on this file system became inaccessible yesterday, 3 of them showed the LBUG at ofd_grant.c:352:ofd_grant_incoming with negative grant values. I disabled the automated grant release workaround in case it is related to this occurence. The OSTs are 77-79% full at the moment. After that another OSS went down with the same LBUG.
This coincides with the addition of a new cluster, but we haven't done any I/O from it so far, just mounting. Any advice/thoughts?
|
|
And a specific question, is the LBUG likely addressed by changes upstream or should this be a separate ticket?
|
|
The LBUG in question hasn't been changed, though the grant code has been reworked (a la LU-2049) upstream. The negative grant resulting in LBUG should be separate bug, though it's probably 2.5 only.
|
|
The file system usage has been reduced to ~70%, and we haven't seen -28 issues or LBUGs since then.
You can close this one, we'll consider the fix for -28 issues to be upgrade to 2.8 lustre on the servers at some point in the future.
If the LBUG re-occurs I'll open a new ticket.
Thanks,
Ruth
|
|
Thanks Ruth.
~ jfc.
|
Generated at Sat Feb 10 02:09:31 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.
lu-7510-lbug.txt
zfs.lfs-out.12.02