|
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
[Prev in Thread] | Current Thread | [Next in Thread] |