This tutorial is actively maintained by the Grid'5000 team. If you encounter problems, please report them (see the Support page). Additionally, as it is a wiki page, you are free to make minor corrections yourself if needed. If you would like to suggest a more fundamental change, please contact the Grid'5000 team.
Disk reservation consists in reserving nodes' hard disks, in order to locally store large datasets between your reservations, and avoid needing moving data to nodes at the beginning of each node reservation. Typically, you can reserve disks for several days, store your data on those disks during your first nodes reservation, and then access the data during the subsequent nodes reservations.
The table below shows the cluster compatibility with disk reservation.
|Site||Cluster||Number of nodes||Number of reservable disks per node|
How it works
Disk reservation works with jobs of type deploy and jobs of type noop. You can reserve some disks in the long run with a job of type noop. Then, you may reserve a job of type deploy on the same nodes as those where you reserved your disks.
When the job of type deploy starts, the disks you reserved are enabled by the RAID card of the node, and the other disks are disabled. Reserved disks can only be accessed by the user who reserved them (see also Security issues).
The main commands to reserve disks are given below.
Note that accessing the data stored on reserved disks on nodes is only possible with reservation of type deploy (
The maximum duration of a disk reservation is defined in the Usage Policy.
Reserve disks and nodes at the same time
- Reserve a node with only the main disk (none of the additional disks), on the grimoire cluster
(no change to the way a node was to be reserved in the past, before the disk reservation mechanism existed.)
- Reserve a node with all its disks
(disk_reservation_count is equal to the number of disks which can be reserved on a node.)
- Reserve nodes grimoire-1 and grimoire-2 with one reservable disk per node
Yes, the syntax of the last oarsub command is a bit awkward, so please be careful and mind having:
Reserve disks and nodes separately
You may, for example, decide to reserve some disks for one week, but the nodes where your disks are located only when you want to carry out an experiment.
First: reserve the disks
Since we want to reserve disks only in a first time, we use the noop job type: with this noop job type, OAR will not try to execute anything on the job resources (which is what we want since disk resources are not capable of executing programs).
(Please mind that Jobs of type noop cannot be interactive:
-I -t noop ... is not supported.)
Reserve two disks on grimoire-1 for one week, starting on 2018-01-01:
Or reserve the first two disks on grimoire-2:
Or reserve all disks on two nodes:
Second: reserve the nodes
You can then reserve nodes grimoire-1 and grimoire-2 for 3 hours, in the usual way:
You must respect this order : reserve the disks first, then reserve the nodes. Otherwise the disks you reserved will not be available on your nodes.
Show and use my reserved disks
Reservations of both nodes (processors) and disks are displayed on the following Gantt diagrams:
Once connected to a node in a deploy job with one or more disks reserved locally on the node, several tools can be used to manage the disk(s):
lsblkwill show you the block devices of your disks: sdb, sdc, ... (be careful: sda is the system disk);
- Commands like
partedcan be used to partition the disk, if needed;
mkfscan be used to format the disk.
Mind that the platform provides access to the block devices, but does not manage partitioning nor formatting.
Getting information about disk reservations from OAR and G5K APIs
- The OAR API shows the properties of each resource of a job. You can retrieve the properties of your reserved disks, such as disk or diskpath:
- The Grid'5000 API in version sid also provide some details about disk reservations under the "disks" key of the status and jobs APIs:
The mechanism used to enable/disable disks is designed to avoid mistakes from other users. However, a malicious user could take control of the RAID card, enable any disk, and access or erase your data. Please mind securing your data:
- Keep a copy (backup) in a safe place if relevant for your data ;
- If your data is sensitive, mind using cryptographic mechanisms to secure it.
Also, the data on reserved disks is not automatically erased at the end of your job. If you don't want the next user to access it, you have to erase it yourself.
Finally, of course, no backups of data made on the reserved disks are made.