[lustre-discuss] pool restrictions

Dennis Nelson dnelson at ddn.com
Fri Dec 18 12:02:23 PST 2015

See this bug.


Dennis Nelson
Mobile: 817-233-6116

Applications Support Engineer
DataDirect Networks, Inc.
dnelson at ddn.com

On 12/18/15, 1:52 PM, "lustre-discuss on behalf of Crowe, Tom"
<lustre-discuss-bounces at lists.lustre.org on behalf of thcrowe at iu.edu>

>Greetings All,
>I have been testing lustre pools, attempting to ³restrict² data placement
>by setting the striping information for a top level directory of a
>specific user/project with Œlfs setstripe ­p fsname.poolname
>This works as desired, however, when I become the non-root user that has
>access to this top level directory, and perform a Œlfs setstripe ‹c 4¹ on
>a new file and or directory under the top level directory, the pool
>information is not ³inherited². The lfs setstripe command happily
>completes, and sets the file/dir striping to 4 OST¹s, which are not
>members of the pool.
>I believe a client side mount option of nouser_xattr ³might² prevent this
>behavior, but it would also likely prevent ANY setstripe operations from
>occurring on that client, as well as other extended attributes (ACL¹s,
>So my questions are 2 fold.
>1. Am I missing anything about how pool¹s behave? Should a file/dir¹s
>previously defined pool be ³inherited² if no NEW pool is passed as a part
>of the lfs setstripe command? Is there another way to ³contain² a specific
>user¹s data into a limited set of OST¹s?
>2. Is there any other way other than the client mount option nouser_xattr
>to prevent users from altering striping? In a scenario where we are not in
>control of the clients, it would be most helpful to set a global (MDT)
>parameter to prevent user¹s ability to use/set extended attributes.
>Thanks for your input.
>-Tom Crowe
>lustre-discuss mailing list
>lustre-discuss at lists.lustre.org

More information about the lustre-discuss mailing list