qemu-block
[Top][All Lists]
Advanced

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

Re: [PATCH v4 07/30] qcow2: Document the Extended L2 Entries feature


From: Eric Blake
Subject: Re: [PATCH v4 07/30] qcow2: Document the Extended L2 Entries feature
Date: Wed, 15 Apr 2020 16:13:28 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

On 4/15/20 2:11 PM, Alberto Garcia wrote:
On Fri 10 Apr 2020 11:29:59 AM CEST, Vladimir Sementsov-Ogievskiy wrote:
Should we also document that extended L2 entries are incompatible
with raw external files? [...] After all, when raw external file is
enabled, the entire image is allocated, at which point subclusters
don't make much sense.

It still may cache information about zeroed subclusters: gives more
detailed block-status.

That's a good point about one reason why it might be useful.


So shall I forbid extended_l2 + data_file_raw then?

I wonder, if the only problem is that it's just not very useful, does it
make sense to add additional complexity and restrictions to the code
simply to prevent the user from making a sub-optimal choice?

At this point, I'm not seeing a technical reason why we have to forbid subclusters with data-file-raw. Mixing may be inefficient compared to using raw-data-file without subclusters, but inefficiencies are not worth the code bloat to forbid the combination. If we come up with a scenario where the mix would cause data corruption, that's a different story, but I'm not seeing such a reason at the moment.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]