Space reclamation / UNMAP on RHEL or CentOS 7

What is Space Reclamation?

This feature supports Thin Provisioned environment, and it is the process of freeing space from the storage system that has already been freed from the host file system.

A host file system contains metadata to keep track to know which blocks are available to store new data and which blocks contain actual data and must not be overwritten. This metadata is stored within the LUN. When a file is deleted in the host file system, the file system metadata is updated to mark that file's blocks as free space. Total file system free space is then recalculated to include the newly-freed blocks. To the storage system, these metadata updates appear no different than any other writes being performed by the host. Therefore, the storage system is unaware that any deletions have occurred.


What is Unmapping?

Unmapping is a process which de-allocates relationship between LBA and a physical block in a logical unit.


Reclamation within RHEL and CentOS:

RHEL / CentOS 6.x and later versions of operating systems have introduced SCSI UNMAP command in their propiratory EXT4 filesystem, to support releasing of free space from SAN platforms. This is being done by UNMAP command. The Linux kernel discard requests to inform the storage that a given range of blocks is no longer in use or not really having any valid data.

This can be done by two ways:

Method 1: Create EXT4 file-system and mount it with "discard" option, which automatically sends SCSI UNMAP command from host to array as soon as blocks on the storage frees up.

[root@localhost ~]# mkfs.ext4 /dev/sdb
mke2fs 1.42.9 (28-Dec-2013)
/dev/sdb is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
1310720 inodes, 5242880 blocks
262144 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2153775104
160 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done


[root@localhost ~]# mkdir /space_reclaim_dir

[root@localhost ~]# mount -o discard /dev/sdb /space_reclaim_dir/

[root@localhost ~]# mount | grep "/dev/sdb"
/dev/sdb on /space_reclaim_dir type ext4 (rw,relatime,seclabel,discard,data=ordered)


Method 2: Another method is running "fstrim" command as per user requirement on a mounted partition or disk to free up unused blocks:

I have a mounted disk which is not mounted using "discard" option.

[root@localhost ~]# mount | grep "/dev/sdb"
/dev/sdb on /space_reclaim_dir type ext4 (rw,relatime,seclabel,data=ordered)

[root@localhost ~]# fstrim -v /space_reclaim_dir

In case you want to freeup unused blocks from all of the mounted partitions then run:

[root@localhost ~]# fstrim -a

NOTE:

If your mounted device doesn't support UNMAP operation then you might see this error:

[root@localhost ~]# fstrim -v /no_space_reclaim_dir
fstrim: /no_space_reclaim_dir: the discard operation is not supported

Also to verify TRIM support on all of the devices run :

[root@localhost ~]# lsblk --discard
NAME            DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                    0        0B       0B         0
├─sda1                 0        0B       0B         0
└─sda2                 0        0B       0B         0
  ├─centos-root        0        0B       0B         0
  └─centos-swap        0        0B       0B         0
sdb                    0        0B       0B         0
sr0                    0        0B       0B         0

check the values of DISC-GRAN (discard granularity) and DISC-MAX (discard max bytes) columns. Non-zero values indicate TRIM support. In current output none of the disks supports "TRIM" or UNMAP feature.