Condor's original premise was to have long running compute jobs on distributed nodes with no shared filesystem. Of course, they played all kinds of dirty tricks to make this work including intercepted libc and system calls.
I see no reason cleverly wrapped slurm jobs coudln't do the same, either prestaging files that normally would be on a shared fs or wrapping calls or maybe even using parts of condor. But slurm wasn't designed to do this, so you'd have to add your own mechanisms for it. On Fri, Jun 19, 2020 at 8:20 AM Riebs, Andy <andy.ri...@hpe.com> wrote: > > David, > > > > I’ve been using Slurm for nearly 20 years, and while I can imagine some > clever work-arounds, like staging your job in /var/tmp on all of the nodes > before trying to run it, it’s hard to imagine a cluster serving a useful > purpose without a shared user file system, whether or not Slurm is involved. > > > > Having said that, I hope that someone comes up with a real use case to help > me see something that I don’t currently see! > > > > Andy > > > > From: slurm-users [mailto:slurm-users-boun...@lists.schedmd.com] On Behalf Of > David Baker > Sent: Friday, June 19, 2020 8:05 AM > To: Slurm User Community List <slurm-users@lists.schedmd.com> > Subject: [slurm-users] Slurm and shared file systems > > > > Hello, > > > > We are currently helping a research group to set up their own Slurm cluster. > They have asked a very interesting question about Slurm and file systems. > That is, they are posing the question -- do you need a shared user file store > on a Slurm cluster? > > > > So, in the extreme case where this is no shared file store for users can > slurm operate properly over a cluster? I have seen commands like sbcast to > move a file from the submission node to a compute node, however that command > can only transfer one file at a time. Furthermore what would happen to the > standard output files? I'm going to guess that there must be a shared file > system, however it would be good if someone could please confirm this. > > > > Best regards, > > David > > > >
