On Monday, 30 April 2018 7:05:13 PM AEST Ondrej Kozina wrote: > On 04/30/2018 03:52 AM, Steven Haigh wrote: > > 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. > > This is often undefined (moreover, starting with kernel commit > 48920ff2a5a940cd07d12cc79e4a2c75f1185aee it's guaranteed to be > undefined). You can't expect the discarded area to be zeroed unless you > overwrite it with zeroes explicitly. Interesting. I should also note that I'm running kernel 4.14.x (currently 4.14.34, will be 4.14.38 after a reboot) - which is not stock CentOS. See - what I find interesting is that even if I do zero the data in the Windows VM via sdelete - which creates a file full of zeros, then deletes it. Then I create a snapshot, and use dd to make that into a file, the size is still ~41Gb for the 50Gb image. This seems to indicate that the TRIM operating is discarding the zeros that was written to it - which seems somewhat correct - but not optimal for imaging! I'm starting to wonder if the only want to get the smaller ~12Gb sized compressed images would be to disable TRIM completely - and therefore just leave the sectors lying around with zeros in them. -- Steven Haigh 📧 netwiz@xxxxxxxxx 💻 https://www.crc.id.au 📞 +61 (3) 9001 6090 📱 0412 935 897
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
