Manage a Data Volume

Owned by Audrey Stott
Last updated: Mar 13, 2023 by Gregory OrangeVersion comment
8 min read

This page:

After creating your instance, it is important to have a place to hold and process your data. The preferred way to do this is with a data volume attached to your instance. This is better than using the root volume of your instance for processing data, for multiple reasons:

  • If the root volume runs out of space because it is filled up with data, it can cause the instance to become unstable, including being unable to SSH to it.
  • A data volume can be more easily moved between instances. Moreover, if the existing instance needs to be rebuilt, the contents of any data volumes will not be affected.

Note that data volumes in Nimbus are not intended for long-term storage, and are not backed up. They are meant more as local scratch space for data processing. For longer-term storage, you should consider using Acacia object storage, which you can access from your Nimbus instances (see https://support.pawsey.org.au/documentation/display/US/Manage+your+Acacia+Object+Storage for further information).


Create a Data Volume

  1. Log in to the Nimbus dashboard.

  2. Navigate to Volumes -> Volumes, then click [+ Create Volume] to bring up the Create Volume dialogue window.

    1. Enter a volume name (it doesn't have to be unique, as long as it helps make it recognisable from your list of volumes).
    2. Enter a Size in gigabytes
    3. Click on Create Volume

Once created, it will be listed with status Available on the Volumes page.


Attach a Data Volume

  1. Back on the Volumes page, click the drop-down arrow next to Edit Volume and click Manage Attachments.
  2. Select an instance to attach this volume to

  3. Click on Attach Volume

Once attached to an instance, you will see an entry appear under the Attached To column, usually in the format /dev/sdX on <your-instance-name>.


vdX versus sdX

It is worth noting that for any instances created before May 2022, all attached disks appear within the operating system with device names in the format /dev/vdX . But for those instances created after this date, the format has changed to /dev/sdX . The reason for this is a change in how the disks are presented to the instances, so that they appear as physical disks rather than virtual (for the rest of this document, if you are using an older instance, replace /dev/sdX with /dev/vdX ).

However, an unintended side-effect of this change is that these device names get swapped around between attached disks, in particular after an instance is rebooted. This swapping of names is not reflected in details presented by the Nimbus dashboard. So if a data volume is listed in the Volumes section of the dashboard as attached with the device name /dev/sdc , within the operating system that same data volume may actually be using /dev/sdb (to re-iterate, this issue does not affect older instances using /dev/vdX for device naming).

As a result, when identifying and mounting your data volumes, the preferred method is to use the UUID rather than the device name. This will be discussed later.

Create a Filesystem

Before you can start using a newly created data volume, you first need to create a filesystem on it. This is done within the instance, so you will need to log in to the instance via SSH. 

Do this step only once; doing this on an existing data volume will wipe the contents of it.


You may see the device /dev/sda1 when working with volumes and filesystems, e.g. with the df command. This is the root volume, mounted at / (known as slash or root), where the operating system and system files are stored. You will not be performing any format or mount commands on this device.

Similarly, there is a 64MB disk that is created with your instance, which contains the metadata needed to boot it each time. By default it is named /dev/sdb , but after attaching one or more data volumes and rebooting the instance, it will be renamed to /dev/sdc or /dev/sdd . Do not mount or format this disk. For this reason, you must be careful to check the size of the disk you are performing mount or format commands on.


  1. First identify the data volume to be formatted. The lsblk command can be used for this, ignoring the entries with loop in the name: 

    $ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0     7:0    0 55.6M  1 loop /snap/core18/2566
loop1     7:1    0 55.6M  1 loop /snap/core18/2560
loop2     7:2    0 99.5M  1 loop /snap/go/9952
loop3     7:3    0   48M  1 loop /snap/snapd/17336
loop4     7:4    0 63.2M  1 loop /snap/core20/1623
loop5     7:5    0 63.2M  1 loop /snap/core20/1634
loop7     7:7    0   48M  1 loop /snap/snapd/17029
loop8     7:8    0 99.6M  1 loop /snap/go/9981
sda       8:0    0   40G  0 disk
├─sda1    8:1    0 39.9G  0 part /
├─sda14   8:14   0    4M  0 part
└─sda15   8:15   0  106M  0 part /boot/efi
sdb       8:16   0   64M  0 disk
sdc       8:32   0    5G  0 disk


    In the above example, we have attached a 5GB data volume, so we can see that it is currently using the device name sdc (remember that this may change after rebooting, so you should check again if you restart your instance).

  2. Once identified, format it into an EXT4 file system:

    $ sudo mkfs.ext4 /dev/sdc

Depending on the size of the data volume you have created, you may need to wait several seconds for the format to complete.

Mount the Filesystem

  1. Once you have created a filesystem on your data volume, you can now look up the UUID for it: 

    $ sudo blkid
/dev/sda1: LABEL="cloudimg-rootfs" UUID="117a31f0-8d07-42f6-b249-a932b5bfb017" TYPE="ext4" PARTUUID="af03de76-4498-42d1-845d-1335f40797bf"
/dev/sda15: LABEL="UEFI" UUID="9EB4-CF73" TYPE="vfat" PARTUUID="38c1dbc6-4122-4216-955c-6332043ded3d"
/dev/sdb: SEC_TYPE="msdos" LABEL="config-2" UUID="3705-E4F8" TYPE="vfat"
/dev/sdc: UUID="b88679ef-61b3-49e7-baaa-0093a6211259" TYPE="ext4"

    In the above example, we know that our data volume is currently using the device name sdc , and that it is in ext4 format, so the UUID is b88679ef-61b3-49e7-baaa-0093a6211259 .

    1. If your data volume does not appear in this list, re-run it with the "-c /dev/null" flag to bypass the cache: 

      $ sudo blkid -c /dev/null

  2. If you don't already have a directory created as a mount point for the data volume, create it now, and change the owner of it to the username you are logged in to the instance with (ubuntu in our example): 

    $ sudo mkdir /scratch
$ sudo chown ubuntu:ubuntu /scratch

  3. Now that you have both the UUID of your data volume and a mount point in the filesystem, you can mount the volume (remember, the UUID below is just an example; substitute in your own data volume's UUID):

    $ sudo mount UUID="b88679ef-61b3-49e7-baaa-0093a6211259" /scratch

    Make a note of this specific command line (including the UUID and the mount point specific to your data volume), so that you can re-run it if and when your instance is rebooted.

  4. Use df to confirm that you can see it mounted (bottom entry in the example below):

    $ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G     0  2.0G   0% /dev
tmpfs           395M  988K  394M   1% /run
/dev/sda1        39G   18G   21G  47% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/sda15      105M  4.4M  100M   5% /boot/efi
/dev/loop2       56M   56M     0 100% /snap/core18/2560
/dev/loop0       48M   48M     0 100% /snap/snapd/17336
/dev/loop1       48M   48M     0 100% /snap/snapd/17029
/dev/loop3       56M   56M     0 100% /snap/core18/2566
/dev/loop5      100M  100M     0 100% /snap/go/9952
/dev/loop4      100M  100M     0 100% /snap/go/9981
/dev/loop6       64M   64M     0 100% /snap/core20/1634
/dev/loop7       64M   64M     0 100% /snap/core20/1623
tmpfs           395M     0  395M   0% /run/user/1000
/dev/sdc        4.9G   24K  4.6G   1% /scratch

You have now successfully attached and mounted your data volume.


Re-mount the Data Volume After a Reboot

If your instance is ever restarted or shut down after mounting the data volume, you will need to re-mount the volume after your instance starts back up. To do this, simply re-run the same mount command, with the same UUID and mount point as when you first mounted it (the UUID will not change between reboots). If you do not have the data volume's UUID recorded anywhere, refer to the section "Mount the Filesystem" above for the steps on how to find it.


Resize a Volume

It is possible to resize an existing data volume to make it larger, if additional space is required in an instance. This option is dependent on a few things:

  • You need to have sufficient volume storage quota in your project. Go to the Overview page on the Nimbus dashboard to see how much volume storage is available.
  • You cannot resize a root volume of an instance (the volume mounted as /dev/sda1 or /dev/vda1 inside the instance). If you require a larger root volume, your only option is to delete the instance and re-create it with a larger root volume on the Source section during instance creation.
  • You cannot shrink an existing volume. The new volume size must be larger than the old size.

Provided it meets all these requirements, you can resize a volume by the following steps:

For the following steps, ensure to replace /scratch with your relevant mount point. E.g. you may have named it /data or /my-data.

  1. Log on to the instance, and make sure that any filesystems on that volume are unmounted (use umount if it is mounted):


    $ df -h
$ sudo umount /scratch
  2. Leaving your instance login active, log on to the Nimbus dashboard, go to the Volumes page, and select Manage Attachments from the drop-down menu to the right of the volume
  3. Click Detach Volume, and confirm
  4. Once detached, select Extend Volume from the drop-down menu to the right of the volume
  5. Enter the new size in GB (it must be larger than the current size), then click Extend Volume
  6. To re-attach the volume, select Manage Attachments from the drop-down menu to the right of the volume
  7. Select the instance you want to attach it to, make a note of the value of the Device Name field (usually /dev/sdc), then click on Attach Volume

    1. Go back to your active instance login from step 2, and check for the UUID of that volume: 

      $ blkid

/dev/sda1: LABEL="cloudimg-rootfs" UUID="095994dc-6b15-45a9-bb21-a1c68493be18" TYPE="ext4" PARTUUID="3632202a-4dcc-4d02-8249-d55b4719ce75"
/dev/sdc: UUID="0d5a2683-2645-4b84-bad0-256d0f1693a8" TYPE="ext4"

    2. Make sure that the operating system can see the attached volume: 

      $ sudo fdisk -l /dev/sdc


  8. Run a filesystem check on the partition first (assuming that the partition is /dev/sdc, although fdisk will tell you if the partition has a different name like /dev/sdc1):

    $ sudo e2fsck -f /dev/sdc


  9. Resize the partition to use the additional space added to the volume:

    $ sudo resize2fs /dev/sdc


  10. You can now mount the volume again (replace /scratch with the mount point you normally use for the volume):

    $ sudo mount UUID="0d5a2683-2645-4b84-bad0-256d0f1693a8" /scratch



Back to:

Access and Use Your Nimbus Instance