Volume Shrinking and Expansion

The volume shrinking feature (available in Lightbits Version 3.0 and above) must be completed in a correct order. The layers above the block volume (such as the filesystem) must be shrunk first. If the volume is shrunk first, the filesystem could be corrupted - which could cause data loss.

To correctly shrink a volume, first shrink the filesystem (or any layers above), and shrink the Lightbits volume at the end.

Although there are many possible use cases with NVMe, we will use the following example: a simple ext4 filesystem on top of an NVMe volume. However, note that the same logical progression will apply to the rest (shrinking from the top down).

A common use case is using the XFS filesystem on top of an NVMe volume. However, as XFS does not directly support shrinking, the process is more involved: back up the data, shrink the volume, install fresh XFS on the volume, and copy the data back.

For this example, let's assume that there is a Lightbits volume named vol01, which is 2 TiB and is connected to a client as /dev/nvme0n1. This volume has a ext4 filesystem on it. Use the following steps to shrink it to 1 TiB.

During these operations, you will not have to NVMe disconnect the volume. It can be done while it is connected. However, the filesystem must be unmounted first as resize2fs does not support online shrinking (it only supports online expansion - see the next section for more details).

  1. Unmount the filesystem:
Copy
  1. From the client, shrink the filesystem to 1 TiB:
Bash
Copy

The operation will not run and resize2fs will ask for a filesystem check to ensure that there are no filesystem errors before the shrinking operation is started.

Although resize2fs asks to run e2fsck with option -f (which forces a scan on the filesystem even if it is healthy), do not do that. Instead, first run a e2fsck in read-only mode using the -n flag. After that shows no errors, run it with the -f flag. This is because filesystem checks have a filesystem repairing algorithm that sometimes does more harm than good, and might leave the filesystem more corrupt and unmountable. However, if that is your only choice (i.e., the read-only result showed errors), back up your filesystem and then run e2fsck with option -f at your own risk.

Kick off a read-only filesystem check.

Bash
Copy

As the result was "clean", we can run the filesystem check with option -f.

Bash
Copy

Now we can successfully run the resize2fs operation again.

Bash
Copy
  1. Collect the exact size of the new filesystem in bytes. There are multiple methods to do this. Here is one of them:
Bash
Copy

Note that 1099511627776 bytes is exactly 1 TiB.

  • To calculate the exact filesystem size, do not use "df -B1", as that does not include the filesystem overhead.
  • Also, do not use "nvme list" or "lsblk", as that provides the volume level size and not the filesystem size.
  • The output of the resize2fs operation actually shows the final filesystem size: "the filesystem on /dev/nvme0n2 is now 268435456 (4k) blocks long". Calculate the filesystem size in bytes by multiplying the two values: 268435456 x 4096 = 1099511627776.
  1. From a Lightbits server, shrink the associated volume to 1 TiB. Note that for shrinking, the --force flag must be used.

The volume must be shrunk to the exact same size as the filesystem or larger. This means that it cannot be even one byte smaller than the filesystem.

  1. From the client, verify that the smaller size is reported at the block level via lsblk or nvme list. To get the exact byte size, use blockdev --getsize64.
Bash
Copy

Volume Expansion

Expanding volumes is done in reverse order of shrinking. First, the volume is expanded via lbcli and then the layers above are expanded. Trying to expand in the wrong order will simply error out without doing any harm.

Although there are many possible use cases with NVMe, we will only consider the following example: a simple ext4 filesystem on top of an NVMe volume. However, the same logical progression will apply to the rest. Expand from the bottom to the top.

A common use case is using the XFS filesystem on top of an NVMe volume. XFS supports online expansion via "xfs_growfs /mount/point -D size" (meaning that it can be mounted during expansion). The only requirement is to ensure that the underlying block NVME block device has been expanded as well.

Following a similar configuration from above, assume that there is a Lightbits volume named vol01, which is 2 TiB and is connected to a client as /dev/nvme0n1. This volume has a ext4 filesystem on it. Use the following steps to expand it to 3 TiB.

  1. From a Lightbits server, expand the volume. Note that for expanding, the --force flag is not required.
Bash
Copy
  1. From the client, expand the volume.

You do not need to unmount the filesystem, as resize2fs supports online expansion.

  1. Verify the new block level and filesystem size (see the section above for reference).
Bash
Copy
Type to search, ESC to discard
Type to search, ESC to discard
Type to search, ESC to discard