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
