Hi all,
I've recently deployed a new system and noticed that the backup image of
a few Windows VMs running on Xen is much larger on the new system than
the older ones - which don't have the luks layer.
The setup is as follows:
2 x Intel 960Gb SSDs
/dev/md1 = mdadm RAID1
/dev/mapper/{uuid} = luks on top of /dev/md1
/dev/vg_* = lvm on top of luks
I create the backup by creating an LVM snapshot of the LV, then using dd
to copy that snapshot to a file - piping through pigz on the way.
I have noticed that since moving to SSDs and luks between the RAID and
LVM layers, the backup size for a ~50Gb windows system has increased
from ~12Gb to ~42Gb.
In the Windows VM, I used to run the Windows Powertool 'sdelete -z c:'
to zero out free space. This then deletes the file afterwards - which I
believe would now cause TRIM to remove the file all the way through the
stack. (fstrim on linux based VMs works fine - but we don't back them up
this way).
What would be the expected outcome when the dd reads the TRIM'ed space
on the snapshots of these Windows VMs? The lack of compressability of
the free space now would suggest that maybe the raw read on a TRIMed
sector would return random data.
Can anyone share some insight into how this interaction would work? Or
if there are better ways to take images of LV snapshots in this
environment?
--
Steven Haigh
? netwiz@xxxxxxxxx ? http://www.crc.id.au
? +61 (3) 9001 6090 ? 0412 935 897
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
