Re: mdadm, luks, lvm, vm & trim

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux