On Thu 02 Jul 2020 05:09:47 PM CEST, Max Reitz wrote: >> Without a backing file, there is no read required - writing to an >> unallocated subcluster within a preallocated cluster merely has to >> provide zeros to the rest of the write. And depending on whether we >> can intelligently guarantee that the underlying protocol already >> reads as zeroes when preallocated, we even have an optimization where >> even that is not necessary. We can still lump it in the "COW" >> terminology, in that our write is more complex than merely writing in >> place, but it isn't a true copy-on-write operation as there is >> nothing to be copied. > > The term “COW” specifically in the qcow2 driver also refers to having > to write zeroes to an area that isn’t written to by the guest as part > of the process of having to allocate a (sub)cluster.
The question is valid: if the space for the clusters is allocated but the subclusters are not marked as such then any partial write request will need to fill the rest with zeroes (in practice handle_alloc_space() can do that efficiently but that's another question). If there is a backing file then there's no other alternative because we do need to copy the data from the backing file. If there is no backing file perhaps we could allocate all subclusters as well. I suppose we can detect that scenario at that point in the code (I haven't checked) and I don't know what would happen if one later attaches a backing file on runtime using the command-line options. But what I would argue is that I don't see the benefit of using extended L2 entries on an preallocated image with no backing file: other than having twice as much L2 metadata what would be the use? The point of subclusters is that they make allocation more efficient, but if the image is already fully allocated then they give you nothing. Berto