for intermediate/temporary files (ideal when lots of I/O
operations)
variable quota (depends on the node)
no automatic cleaning so it’s up to you!
Good habit: work within a folder with your
login
Storage system
In summary
all these spaces are accessible from all nodes (including the master
node)
except for the /scratchlocal/ spaces which are specific
to each node
Storage accessibility on the
cluster
/!\ when using temporary spaces, please:
work within a folder containing your login
clean up after yourselves!
Storage system
Where to save what?
➜ /store/EQUIPES
- raw data &
final processed data (for safe keeping) - all data
& protocoles that should be accessible by the team
and that cannot be easily re-generated
➜ /store/USERS
- personal but
professional data (e.g. course material for PhD students or MDC, work
contracts etc.)
- temporary data that
needs to be accessible from all nodes (e.g. a copy of a small database
fetched from the internet, non-dividable files, etc.) - data that is
copied from somewhere else (e.g. for sharing with other
teams)
➜ /scratchlocal
- temporary data that
doesn’t have to be accessible from all nodes (e.g. intermediate files
generated by a tool)
/!\ for temporary spaces, remember to delete your data when you’ve
finished
Storage system
Quotas
Coming soon… with the migration from Compelent to CEPH storage in
2025
In the mean time, you can use traditionnal linux commands such
as:
df -Th
du -ch --max-depth=1 <folder name>
e.g.
$ du -ch--max-depth=1 /store/EQUIPES/BIOI2/92G /store/EQUIPES/BIOI2/MEMBERS844M /store/EQUIPES/BIOI2/ADMIN3,3G /store/EQUIPES/BIOI2/FORMATIONS97G total
Programme
Introduction
Storage system
⇨ Computational resources ⇦
nodes
partitions
Jobs
Software
A few tips
Computational resources
Nodes
slave nodes are identical in terms of OS
& software
Computational resources
Nodes
slave nodes are identical in terms of OS
& software
BUT are different in terms of number of
CPUs, Memory, GPUs etc.
Computational resources
Nodes
slave nodes are identical in terms of OS
& software
BUT are different in terms of number of
CPUs, Memory, GPUs etc.
nodes belong to 1 or several partitions
NB: the above partitions are invented
names for illustrational purposes
Computational resources
Partitions on the I2BC
cluster
different partitions = different properties
common: access to all “shared” or “common” nodes
(default)
runXX (XX=2, 4, 8, 16, 32): when several jobs, auto
management to limit to XX jobs running at a time
<group-specific>: priority (or exclusive usage)
for group members who financed these nodes
smallgpu: access to nodes with small mem GPUs
lowprio & lowpriogpu: access to more
nodes but job could be suspended for a while or stop/restarted,
respectively
Programme
Introduction
Storage system
Computational resources
⇨ Jobs ⇦
SLURM scheduler
key commands
third-party commands
Software
A few tips
Jobs
Job = any task you want to
run
Scheduler = resource manager =
SLURM
manages resources
allocates jobs to the right nodes
monitors job status
reports
=> On a cluster, you run jobs through the scheduler
Key commands (native to
the scheduler)
What?
SLRUM
submit a job
sbatch & srun
list all running or queuing jobs
squeue
delete a job
scancel
Jobs
Key commands (native to
the scheduler)
sbatch & srun to reserve resources
Jobs
Key commands (native to
the scheduler)
sbatch & srun to reserve resources
=> you’re given a “job id”
Jobs
Key commands (native to
the scheduler)
sbatch & srun to reserve resources
=> you’re given a “job id”
Jobs
Key commands (native to
the scheduler)
sbatch [options] myscript.sh [script arguments]:
“letter in postbox”
Material under CC-BY-SA
licence
