See this bug. https://jira.hpdd.intel.com/browse/LU-5916
-- Dennis Nelson Mobile: 817-233-6116 Applications Support Engineer DataDirect Networks, Inc. [email protected] On 12/18/15, 1:52 PM, "lustre-discuss on behalf of Crowe, Tom" <[email protected] on behalf of [email protected]> 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 >[email protected] >http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org _______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
