Hi Andreas,
Indeed, we’re running 2.10.7 from DDN. Unfortunately, updating to more
recent Lustre versions might be a hard sell to our admins without a solid case.
It’s an odd problem, since we haven’t been able to track down a correlation of
the behavior with anything—it only affects
Chris,
this looks like a bug that "lfs getstripe -M" is not using supplementary
groups, or similar. You wrote that the directory has GID=130817, so this is
not the primary GID of the user accessing it, so it must depend on the
supplementary group permissions to access it. The "regular" ls
Hi Andreas,
It doesn’t appear to be this issue. I verified the client “id” and server
“l_getidentity -d” views before and after issuing an “ls” as the user to get
getstripe working, and there’s no change.
Client:
el3:~> id
uid=131364(***) gid=131364(***)
Good afternoon, All
I hope everyone is doing well.
I had a few questions concerning *LU-13645 - Various data corruptions
possible in lustre* [https://jira.whamcloud.com/browse/LU-13645].
We are looking at deploying Lustre 2.12.5 and while browsing JIRA, this
particular issue caught my