On 12.12.18 09:36, Vladimir Sementsov-Ogievskiy wrote: > 13.10.2018 15:58, Max Reitz wrote: >> On 10.10.18 18:59, Vladimir Sementsov-Ogievskiy wrote: >>> 10.10.2018 19:55, Vladimir Sementsov-Ogievskiy wrote: >>>> 10.10.2018 19:39, Vladimir Sementsov-Ogievskiy wrote: >>>>> 17.08.2018 15:22, Vladimir Sementsov-Ogievskiy wrote: >>>>>> Rewrite corrupted L2 table entry, which reference space out of >>>>>> underlying file. >>>>>> >>>>>> Make this L2 table entry read-as-all-zeros without any allocation. >>>>>> >>>>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com> >>>>>> --- >>>>>> block/qcow2-refcount.c | 32 ++++++++++++++++++++++++++++++++ >>>>>> 1 file changed, 32 insertions(+) >>>>>> >>>>>> diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c >>>>>> index 3c004e5bfe..3de3768a3c 100644 >>>>>> --- a/block/qcow2-refcount.c >>>>>> +++ b/block/qcow2-refcount.c >>>>>> @@ -1720,8 +1720,30 @@ static int >>>>>> check_refcounts_l2(BlockDriverState *bs, BdrvCheckResult *res, >>>>>> /* Mark cluster as used */ >>>>>> csize = (((l2_entry >> s->csize_shift) & >>>>>> s->csize_mask) + 1) * >>>>>> BDRV_SECTOR_SIZE; >>>>>> + if (csize > s->cluster_size) { >>>>>> + ret = fix_l2_entry_to_zero( >>>>>> + bs, res, fix, l2_offset, i, active, >>>>>> + "compressed cluster larger than cluster: >>>>>> size 0x%" >>>>>> + PRIx64, csize); >>>>>> + if (ret < 0) { >>>>>> + goto fail; >>>>>> + } >>>>>> + continue; >>>>>> + } >>>>>> + >>>>>> coffset = l2_entry & s->cluster_offset_mask & >>>>>> ~(BDRV_SECTOR_SIZE - 1); >>>>>> + if (coffset >= bdrv_getlength(bs->file->bs)) { >>>>>> + ret = fix_l2_entry_to_zero( >>>>>> + bs, res, fix, l2_offset, i, active, >>>>>> + "compressed cluster out of file: offset >>>>>> 0x%" PRIx64, >>>>>> + coffset); >>>>>> + if (ret < 0) { >>>>>> + goto fail; >>>>>> + } >>>>>> + continue; >>>>>> + } >>>>>> + >>>>>> ret = qcow2_inc_refcounts_imrt(bs, res, >>>>>> refcount_table, >>>>>> refcount_table_size, >>>>>> coffset, csize); >>>>>> @@ -1748,6 +1770,16 @@ static int >>>>>> check_refcounts_l2(BlockDriverState *bs, BdrvCheckResult *res, >>>>>> { >>>>>> uint64_t offset = l2_entry & L2E_OFFSET_MASK; >>>>>> + if (offset >= bdrv_getlength(bs->file->bs)) { >>>>>> + ret = fix_l2_entry_to_zero( >>>>>> + bs, res, fix, l2_offset, i, active, >>>>>> + "cluster out of file: offset 0x%" PRIx64, >>>>>> offset); >>>>>> + if (ret < 0) { >>>>>> + goto fail; >>>>>> + } >>>>>> + continue; >>>>>> + } >>>>>> + >>>>>> if (flags & CHECK_FRAG_INFO) { >>>>>> res->bfi.allocated_clusters++; >>>>>> if (next_contiguous_offset && >>>>> >>>>> hmm, interesting question here: in case of misaligned l2 entry, we >>>>> zero it out only for QCOW2_CLUSTER_ZERO_ALLOC, but not for normal >>>>> clusters? Why? I think it is ok to mark as zero misaligned normal >>>>> cluster l2 entry, otherwise we'll have fatal corruption on any >>>>> operation to this cluster. >> >> Because for zero clusters the solution is clear. We just throw away the >> obviously wrong preallocation information, but the cluster data stays >> the same (zero). So there is no data loss. >> >> For normal clusters, you definitely destroy the data by zeroing them out. >> >>>> or we can just align them down. >> >> Which would destroy the data as well. >> >> You can argue that if the value is misaligned, it is extremely likely to >> be just garbage as a whole, though. But in any case, it is not obvious >> what to do and always means data loss (which is different from zero >> clusters, where you can just keep them zero). >> >> The clearest and most obvious solution would be to allocate a new >> cluster and copy the unaligned data there. Maybe that doesn't make >> sense because the data is probably garbage anyway, but it definitely >> won't harm. > > > but what to copy? I think, it is mostly impossible that there is a misaligned > data cluster. More probable is just partly wrong l2 entry.
What do you mean by "partly"? I think having eight bytes "partly" wrong is not very probable either. I do agree that it's more likely that the L2 information is just garbage than that the cluster base really is misaligned. But I think it would be garbage as a whole. > So, in your way we will lose this data (as we lose l2 entry, our last hope). So you think we should set the zero bit and leave the rest of the cluster as it is? But the resulting image would not be correct (because the preallocation offset is wrong), so I don't see that as a good way of repairing. On one hand I think we want some repair option to explicitly acknowledge data loss. Like invalid bitmaps being removed or invalid L2 entries being set to some value that is valid. On the other, I would imagine that one usually runs qemu-img check without -r on a broken image first to see what's up; at least if they intent to have a deep look into it at all. I think people should be aware that -r all may destroy these kinds of leads. But in any case, since I think the chances of the L2 entry only being partly wrong are very small, I think it doesn't bring much to keep that data around anyway. I only find it useful in finding out why the corruption occurred in the first place (by seeing what kind of data it was overwritten with). > Finally, what to do with > misaligned cluster on check? We definitely should do something, as trying to > access such cluster corrupts qcow2 in qemu. Well, I gave a description of what I think should be done; which is to allocate a new cluster, copy the unaligned data there, and then make the entry point to that new cluster. > What about an additional flag like "-align-misaligned-clusters-down"? It would probably make more sense to add flags to the qemu-img check infrastructure than adding a new -r mode, yes. Max
signature.asc
Description: OpenPGP digital signature