The current OST Pools feature is "advisory" only. That means it can be used to specify the default OSTs for new files, but it does not restrict the OSTs that could be selected to that pool, nor prevent users from selecting a different pool entirely.
There has been some discussion about implementing OST or pool quotas to restrict users to specific OSTs (e.g. local vs remote) or away from other OSTs (e.g. flash), but there aren't specific plans to implement this yet. Also, at some point in the nearish future we'll be adding a filesystem global default layout that could specify a pool if none is specified otherwise. That is for the ~2.10 timeframe. Cheers, Andreas > On Dec 18, 2015, at 12:52, Crowe, Tom <[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
