2012/12/16 Aaron Knister <[email protected]> > Hi Marcin, > > Hi Aaron,
> Could you describe the use case for preventing access when the lustre > license isn't specified? That might help me offer a better solution. > For instance, I know that my lustre installation can support efficiently only 20 running jobs, but I have more CPU resources so I'd like to prevent running more than 20 jobs on lustre, but allow other jobs (using only local scratch or even do not using scratch at all). > > Off the top of my head I could see using prolog/epilog scripts to mount > and unmount lustre as required however this only works if your nodes are > job-exclusive (one job per node). > This is not my case, I have heterogenous installation with 64 cores in a few nodes on which are sometimes running 64 separate jobs :) > > Another option would be to use a chroot environment for each job and only > bind-mount required filesystems. This approach has a lot of overhead, > though and I'm not entirely sure of the implementation details. You could > also try the cgroup namespace subsystem. I did some reading this morning > and can't find documentation for this but I had some vague recollection > that you could control which filesystems are accessible to each namespace. > chroot proposition sounds interesting, I don't know how to use cgroups for filesystem IO operations limiting. thank you, marcin > > Sent from my iPhone > > On Dec 16, 2012, at 10:12 AM, Marcin Stolarek <[email protected]> > wrote: > > Hi all, > > I'm thinking about describing lustre as a licence in our slurm > installation. Do you know any possibility of preventing job from writing > on/reading from a specified file system if user haven't specified > appropriate licence string? > > thanks, > marcin > >
