[lustre-discuss] pool restrictions

[Crowe, Tom]

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