[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/2] qcow2: Force preallocation with data-file-raw
From: |
Kevin Wolf |
Subject: |
Re: [PATCH 0/2] qcow2: Force preallocation with data-file-raw |
Date: |
Tue, 23 Jun 2020 12:04:00 +0200 |
Am 23.06.2020 um 09:28 hat Max Reitz geschrieben:
> On 22.06.20 19:44, Alberto Garcia wrote:
> > On Mon 22 Jun 2020 11:47:32 AM CEST, Max Reitz wrote:
> >>> I don't know the internals of qcow2 data_file, but are we really using
> >>> qcow2 metadata when accessing the data file?
> >>
> >> Yes.
> >>
> >>> This may have unwanted performance consequences.
> >>
> >> I don’t think so, because in practice normal lookups of L1/L2 mappings
> >> generally don’t cost that much performance.
> >
> > ...if the L2 cache size is large enough. Otherwise you need one extra
> > read operation to retrieve the L2 metadata.
> >
> > Possible performance problems when you have preallocation:
> >
> > - If a block hasn't been written yet (it's all zeroes) then you still
> > need to read the L2 entry and read the data block. If there is not
> > L2 table then you can simply return zeroes without going to disk at
> > all. This of course assumes that the contents of the unwritten data
> > block are zeroes.
> >
> > - QEMU still needs to read from disk (and cache in memory) the L2
> > metadata, when it already knows in advance the contents of the L2
> > entry (guest_offset == host_offset).
>
> We could well optimize this regardless of preallocation. With
> data-file-raw, qemu doesn’t have to look at the L2 metadata at all.
>
> So the problem isn’t preallocation at all, it’s the fact that we don’t
> have such an optimization. But note that to implement such an
> optimization, we really do need preallocation: Because it would mean
> that we wouldn’t touch the L1/L2 tables for data-file-raw images during
> runtime, which would effectively make those images empty to today’s qemu
> versions.
It depends. For reads, bypassing the L1/L2 tables is completely fine
with data-file-raw. It may miss opportunities to optimise reading
unallocated/zeroed clusters, but if the data file is actually sparse, it
shouldn't make a big difference. Maybe we should just do this.
For (potentially allocating) writes, you're right that we need to be
more careful. If we want to completely bypass L1/L2 tables,
preallocation is not enough, but we have to make sure that we never
discard any clusters.
Whatever we do for writes will be a non-trivial change. I wonder if it's
really worth doing this for optimisation when nobody uses the feature
yet anyway.
> (OTOH, preallocation would then be pretty much superfluous for all newer
> versions of qemu. To address that, we could then add an incompatible
> version of data-file-raw. But I think we should only think about that
> once we get to that point.)
Well, if we create an incompatible version, we can have one that doesn't
even store L1/L2 tables.
Kevin
signature.asc
Description: PGP signature
- Re: [PATCH 1/2] qcow2: Force preallocation with data-file-raw, (continued)
[PATCH 2/2] iotests/244: Test preallocation for data-file-raw, Max Reitz, 2020/06/19
Re: [PATCH 0/2] qcow2: Force preallocation with data-file-raw, no-reply, 2020/06/19
Re: [PATCH 0/2] qcow2: Force preallocation with data-file-raw, Nir Soffer, 2020/06/21