Hi,
I am not sure the NIDs displayed under ‘exports’ and in the logs are the actual
NIDs used to communicate with, maybe they are just identifiers to describe the
peers.
If you want to restrict a client to a given LNet network for a given mount
point, you can use the ‘-o network=’ mount
Thanks for reporting this. I created Jira ticket LU-15908
(https://jira.whamcloud.com/browse/LU-15908), and pushed patch
https://review.whamcloud.com/47512 to fix the problem.
Cheers,
Sebastien.
> Le 2 juin 2022 à 11:01, Åke Sandgren a écrit :
>
> Sorry, meant master not 2.14, and it's
That is correct, in your case you should set admin and trusted to 1 on your
default nodemap. But that is not really the recommended way to work with
nodemaps. The default nodemap should be restrictive so that unknown clients
ending up in this group are not granted any privileges. And then you
Hi,
It looks like you did not set properties on the default nodemap, which gets
involved for your machine not in the 10.0.1.[35-38] range.
When in use, the nodemap feature does not change anything about UID/GID of
files as stored on servers, it just changes (maps) the way clients see them.
Hi,
Lustre Changelogs are properly generated when a client is accessing Lustre via
a subdirectory mount. And the changelogs can also be retrieved as expected.
What is not possible today is to configure the changelogs mask on a
per-directory basis. This setting is global to each MDT. So what
Hi Thomas,
The phenomenon you observe is likely due to a caching effect on client side. If
you clear the cache with the following command on your clients after the
nodemap definitions have been updated, you should be able to see what you
expect:
client# lctl set_param
