On 05/26/2017 11:11 AM, Kevin Wolf wrote: > > No. This is what you bypass: some analysis for the record.
> * All sanity checks that the block layer does > > * bdrv_inc/dec_in_flight(), which is required for drain to work > correctly. Not doing this will cause crashes. Should not be a problem. We are in the request, which is accounted for the parent. Drain waits parent first and after that switched to child. > * tracked_request_begin/end(), mark_request_serialising() and > wait_serialising_requests(), which are required for serialising > requests to work correctly should not cause a problem as we are protected by meta and this area is not exposed to read operation until fully complete. But yes, not that good. > * Ensuring correct request alignment for file. This means that e.g. > qcow2 with cluster size 512 on a host with a 4k native disk will > break. we have already checked that clusters are aligned. > * blkdebug events yes > * before_write_notifiers. Not calling these will cause corrupted backups > if someone backups file. no as there is no user visible data here, we are writing zeroes where there are zeroes from guest point of view > * Dirty bitmap updates same. The data from the guest point of view is not changed. This is even good that we do not mark this areas as dirty. > * Updating write_gen, wr_highest_offset and total_sectors write_gen is not a problem. It will be set on actual write. total_sectors is changed manually. Agree that this is not really elegant. > * Ensuring that bl.max_pwrite_zeroes and bl.pwrite_zeroes_alignment are > respected yes > And these are just the obvious things. I'm sure I missed some. anyway, this is a good list of things to take into account within bdrv_allocate. But it is important, that from the guest point of view the content of COW areas is not changed and thus we can have some important shortcuts. Den
