After creating your instance, it is important to have a place to store hold and process your data. The usual 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

Create and Attach a Data Volume

Create and attach a volume

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.
   

   Note
   You may see an existing volume already there, with a name like 91bd1e23-ce06-41e0-aeb5-41382df48170. It is most likely the root volume for your instance, and you can ignore it.

   1. Enter a volume nameEnter 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
   

Create a filesystem

Once you have attached the volume as above, confirm that the volume is properly attachedOnce 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. 

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: 

   Code Block
   $ lsblk NAME

1. MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0

1. 7:0 0

1. 55.6M 1 loop /snap/core18/2566 loop1 7:1 0

1. 55.6M 1 loop /snap/core18/2560 loop2

1. 7:

1. 2 0

1. 99.5M 1 loop /snap/go/9952 loop3 7:3 0

1. 48M 1 loop /snap/snapd/17336 loop4

1. 7:

1. 4 0 63.2M

1. 1 loop /snap/core20/1623 loop5 7:5 0

1. 63.2M 1 loop /snap/core20/1634 loop7

1. 7:

1. 7 0 48M 1

1. loop /snap/snapd/17029 loop8 7:8 0

1. 99.6M 1 loop /snap/go/9981 sda 8:

1. 0 0

1. 40G 0 disk

In the output above, there is a 40GB root disk (sda) and 1 x 80GB volume storage disk (sdc).

Check the 80GB volume storage disk:

$ sudo fdisk -l /dev/sdc

You should see this returned:

Disk /dev/sdc: 80 GiB, 85899345920 bytes, 167772160 sectors
Disk model: QEMU HARDDISK   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

(Only new volumes) Format the volume with a new filesystem:

1. ├─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:

   Code Block
   $ sudo mkfs.ext4 /dev/sdc

*** Wait 30 seconds before the next step ***

Mount the filesystem

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: 

   Code Block

   $ sudo blkid /dev/sda1: LABEL="cloudimg-rootfs" UUID="095994dc117a31f0-6b158d07-45a942f6-bb21b249-a1c68493be18a932b5bfb017" TYPE="ext4" PARTUUID="af03de76-4498-42d1-845d-1335f40797bf" /dev/sda15: LABEL="UEFI" UUID="9EB4-CF73" TYPE="vfat" PARTUUID="3632202a-4dcc-4d02-8249-d55b4719ce7538c1dbc6-4122-4216-955c-6332043ded3d" /dev/sdb: SEC_TYPE="msdos" LABEL="config-2" UUID="3705-E4F8" TYPE="vfat" /dev/sdc: UUID="0d5a2683b88679ef-264561b3-4b8449e7-bad0baaa-256d0f1693a80093a6211259" TYPE="ext4"

   Mount the volume (/dev/sdc) to a new directory called /data (making sure to copy the UUID) as such:

   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: 

      Code Block
      $ 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): 

   Code Block
   $ sudo mkdir /scratch $ sudo chown ubuntu:ubuntu /data 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):

   Code Block
   $ sudo mount UUID="0d5a2683b88679ef-264561b3-4b8449e7-bad0baaa-256d0f1693a80093a6211259" /data

   Check your new /data volume is mounted correctly

   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):

   Code Block
   $

lsblk | grep sdc sdc 8:32 0 80G 0 disk /data

5. Check that you can write files to your new volume:

   Code Block
   cd /data touch test.txt

   If you see an error about 'permission denied', you most likely need to change the owner of the volume to ubuntu (that's you!) with the following command

   Code Block

   sudo chown ubuntu /data 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

You can also only mount one data volume with one instance at a time.  If you want to access the same volume from multiple instances, we suggest mounting it on one instance, then sharing it out to the others on your private network via NFS

Re-mount a volume after a reboot

It is possible for the disk name of your volume to change after rebooting your instance. If so, follow the instructions to re-mount your volume with the correct disk name.

First, check the UUID of your volume: 

$ sudo 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"

Mount the volume (/dev/sdc) to your directory (e.g. /data) (making sure to copy the UUID) as such:

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:

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

   Code Block
   $ df -h $ sudo umount /datascratch

   
   

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: 

      Code Block
      $ 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

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

      Code Block
      $ sudo fdisk -l /dev/sdc

      
      

8. Run a file system 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):
   

   Code Block
   $ sudo e2fsck -f /dev/sdc

   
   

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

   Code Block
   $ sudo resize2fs /dev/sdc

   
   

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

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