[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] LUKS: support preallocation in qemu-img
From: |
Daniel P . Berrangé |
Subject: |
Re: [Qemu-devel] [PATCH] LUKS: support preallocation in qemu-img |
Date: |
Thu, 11 Jul 2019 14:56:24 +0100 |
User-agent: |
Mutt/1.12.0 (2019-05-25) |
On Thu, Jul 11, 2019 at 08:50:56AM -0500, Eric Blake wrote:
> On 7/11/19 7:24 AM, Max Reitz wrote:
>
> >>> So it isn’t just me who expects these to pre-initialize the image to 0.
> >>> Hm, although... I suppose @falloc technically does not specify whether
> >>> the data reads as zeroes. I kind of find it to be implied, but, well...
> >>
> >> I personally don't really think that zeros are important, but rather the
> >> level of allocation.
> >> posix_fallocate probably won't write the data blocks but rather only the
> >> inode metadata / used block bitmap/etc.
> >>
> >> On the other hand writing zeros (or anything else) will force the block
> >> layer to actually write to the underlying
> >> storage which could trigger lower layer allocation if the underlying
> >> storage is thin-provisioned.
> >>
> >> In fact IMHO, instead of writing zeros, it would be better to write random
> >> garbage instead (or have that as an even 'fuller'
> >> preallocation mode), since underlying storage might 'compress' the zeros.
> >
> > Which is actually an argument why you should just write zeroes on the
> > LUKS layer, because this will then turn into quasi-random data on the
> > protocol layer.
>
> We want preallocation to be fast (insofar as possible). Writing zeroes
> in LUKS is not fast, because it forces random data on the protocol
> layer; while writing zeroes on the protocol layer can be fast, even if
> it reads back as random on the LUKS layer. If you WANT to guarantee
> reading zeroes, that's image scrubbing, not preallocation. I think this
> patch is taking the right approach, of letting the underlying layer
> allocate data efficiently (but the burden is then on the underlying
> layer to actually allocate data, and not optimize by compressing zeroes
> into non-allocated storage).
On the topic of scrubbing, it would actually be nice to have a
"secure delete" for QEMU block driver formats that can do some
level of scrubbing in software and/or calling out to hardware support.
Similarly to prealloc a choice of 'metadata' or 'full'. Wwith LUKS
you can do well by just scrubbing the image header (which kills the
master decryption key rendering payload useless).
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Re: [Qemu-devel] [PATCH] LUKS: support preallocation in qemu-img, Daniel P . Berrangé, 2019/07/11