[lustre-discuss] pool restrictions

[Dennis Nelson]

See this bug.

https://jira.hpdd.intel.com/browse/LU-5916

-- 
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>
wrote:

>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
>top-level-dir¹.
>
>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,
>etc)
>
>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
>http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org