If you fill the physical space of a VDO volume it will corrupt the data and you will see I/O errors
dmesg will probably look something like this:

[ 3150.967303] XFS (dm-2): writeback error on sector 10950872
[ 3153.384860] XFS (dm-2): metadata I/O error in "xlog_iodone" at daddr 0x1200068 len 64 error 28
[ 3153.384873] XFS (dm-2): xfs_do_force_shutdown(0x2) called from line 1261 of file fs/xfs/xfs_log.c.  Return address = 000000000d11b9e8
[ 3153.384926] XFS (dm-2): Log I/O Error Detected.  Shutting down filesystem
[ 3153.384928] XFS (dm-2): Please umount the filesystem and rectify the problem(s)

The only way to fix this as of 8/21/2018 is to expand the raid.  This should be kept in mind when building VDO volumes.  If you "land-lock" yourself out of the ability to add drive space then you be relying on any backups you might have to recover this data.

Process for recovery:
In this "mini" example we have 4 drives in a raid 5
2 TB - drives
8 TB - Raw
6 TB - Usable after the raid

VDO is setup for 18 TB --name=vdo_data

We artificially create files us in dd if=/dev/urandom and if=/dev/zero.
After the space is consumed we begin to get I/O errors on our mounted share.

Process for fixing:
Check for new vdo size:
vdostats --human-readable
[root@localhost mnt]# vdostats --human-readable
Device                    Size      Used Available Use% Space saving%
/dev/mapper/vdo_data      6.0T      6.0T      0.0B 100%            0%


Unmount your broken clock level mount:
umount /mnt/vdo_data

Add another 2 TB drive to the raid5

Use fdisk -l to make certain you know the device id
In this example our new and 5 drive is: /dev/sdf
Also, take note of the raid size for /dev/md0

Add drive:
mdadm --add /dev/md0 /dev/sdf

Watch process:
watch cat /proc/mdstat 

Grow raid group:
mdadm --grow /dev/md0 --raid-devices=5

Watch process:
watch cat /proc/mdstat

Check raid size:
fdisk -l
You should see /dev/md0 is larger than before:

Grow the Logical volume size of the vdo volume
vdo growLogical --name=vdo_data --vdoLogicalSize=24G

Grow the physical size of vdo
vdo growPhysical --name=vdo_data

Check for new vdo size:
vdostats --human-readable
You should now see available freespace

Repair your file system:
mount -t xfs /dev/mapper/vdo_data /mnt/vdo_data
ummount /mnt/vdo_data
xfs_repair /dev/mapper/vdo_data 
mount -t xfs /dev/mapper/vdo_data /mnt/vdo_data

The final file that filled the drive will be missing data.

Overview

    The following information outlines how the BASH script showsecure works.
In this process we are using a combination of to linux system commands to determine whether a drive is encrypted.
We are using LUKS encryption during the installation process of a Linux install.
During a typical Red Hat installation three partitions are created:
1. efi - location for bootable firmware (Replaces MBR)
2. boot - The main system files that are called by the EFI to be able to boot the partition
3. root - All other Linux data needed to run Linux

LUKS default cipher is aes-cbc-essiv:sha256 
LUKS encrypts the entire block device

Process

    On boot the Linux kernel device mapper calls the LUKS partition.
    The User is immediately prompted for a password to unlock the drive.
    If the correct password is supplied the Linux Kernel maps the encrypted drive for access and the boot process continues.

Weekly Monitoring

    We can prove a drive is encrypted by looking at the block id information.
    In the script below we are looking for two things:

1. Is there a mapped luks drive partition? - Determined with the fdisk command
2. Is the mapped drive the root partition /dev/sda3? - Determined with the blkid command

    A cronjob runs once a week to verify that a drive has been encrypted.
    If the UUID's matched from both check then an emailed is sent stating that the drive encryption is active.
    If the UUID's do not match the an email is sent stating that the drive has not been encrypted.


script

cat showsecure 
-------------------------
!/bin/bash
---- Query Drive Data
driveinfo1=$(/usr/sbin/fdisk -l | /usr/bin/grep "Disk /dev/mapper/luks")
driveinfo2=$(/usr/sbin/blkid | /usr/bin/grep "/dev/sda3")

---- Parse the UUID information looking for a LUKS encryption match
check1=$(echo $driveinfo1 | /usr/bin/grep -oP '(?<=luks-).*(?=:)')
check2=$(echo $driveinfo2 | /usr/bin/grep -oP '(?<=UUID=").*(?=" T)')

----  Comment out the above and uncomment these to prove failure response
-check1=1234567
-check2=7654321

---- Prep information file that will be emailed
   grabhost=$(hostname)
        echo "Linu30 9 * * 3 /root/scripts/showsecure
x Encryption Infomation" > /root/scripts/driveinfo.txt
        echo "Computer: "$grabhost >> /root/scripts/driveinfo.txt

---- Check for LUKS encryption and send report on status
---- Alert on success
if [ "$check1" = "$check2" ]
 then 	
        echo "Drive Encryption Status: Active : ID:" $check1 >> /root/scripts/driveinfo.txt
        mail -s "Linux Encryption Report:" [email protected] [email protected] < /root/scripts/driveinfo.txt

 else
---- Alert on failure
        echo "Drive Encryption Status: !!! Drive is not Encrypted !!! : ID:" $check1 >> /root/scripts/driveinfo.txt
        mail -s "Linux Encryption Report:" [email protected] [email protected] < /root/scripts/driveinfo.txt

fi;
-------------------------
crontab
30 9 * * 3 /root/scripts/showsecure 

openssl
openssl enc -aes-256-cbc -iter 1000 -in myfile.txt -out mysecurefile.txt
openssl enc -aes-256-cbc -iter 1000 -d -in mysecurefile.txt -out myfile.txt

gpg
gpg –cipher-algo AES256 -c myfile.txt
gpg –output list.txt –decrypt myfile.txt.gpg

mkdir /mnt/temp1

pvscan
PV /dev/sda2 VG rhel lvm2 [<49.00 GiB / 0 free]
Total: 1 [<49.00 GiB] / in use: 1 [<49.00 GiB] / in no VG: 0 [0 ]

vgchange rhel -a y
ACTIVE ‘/dev/rhel/swap’ [5.00 GiB] inherit
ACTIVE ‘/dev/rhel/root’ [<44.00 GiB] inherit

lvscan

mount /dev/rhel/root /mnt/temp1/

df -h
fdisk -l /dev/sdc
echo 1>/sys/class/block/sdc/device/rescan
fdisk -l /dev/sdc
cat /proc/partitions | grep sd
pvs
pvresize /dev/sdc
pvs
lvdisplay
lvextend -L+20G /dev/VG_DATA2/lv_data2
xfs_growfs /dev/VG_DATA2/lv_data2
df -h