<div dir="ltr">Hi, unfortunately this didn't work either.<div><br></div><div>Not sure if I could file this as a bug, since I am not sure what caused it.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 27, 2019 at 4:46 PM Mohr Jr, Richard Frank <<a href="mailto:rmohr@utk.edu">rmohr@utk.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> On Jun 27, 2019, at 8:16 AM, Miguel Santos Novoa <<a href="mailto:miguelsn@met.no" target="_blank">miguelsn@met.no</a>> wrote:<br>
> <br>
> For the last couple of weeks we have been adding and removing OSTs, and we were also doing tests with a client using Lustre version 2.12, which this seems our main hypothesis of the problem. We are not sure what is causing this behavior.<br>
> <br>
> From all our clients, we cannot mount lustre any longer, although the active mounts are still serving and no other element seems to be affected. Because of the nature and importance we have not and we don't want to give it a try to reboot the MDS/MDT server.<br>
<br>
It might be a long shot, but you could try dropping caches on the Lustre servers (echo 3 > /proc/sys/vm/drop_caches).<br>
<br>
I have an issue on one of my file systems running Lustre 2.9 that seems to be a bug related to the IB stack.  After a certain point, the servers start getting memory allocation errors.  Existing clients that have lustre mounted work fine, but I can’t mount any new clients.  After dropping caches, I can mount new clients again.  (I realize that you are using tcp instead of IB, but since the symptoms sound very similar to what I have seen, it might be worth a try.)<br>
<br>
--<br>
Rick Mohr<br>
Senior HPC System Administrator<br>
National Institute for Computational Sciences<br>
<a href="http://www.nics.tennessee.edu" rel="noreferrer" target="_blank">http://www.nics.tennessee.edu</a><br>
<br>
</blockquote></div>