On Tue 31 Jan 2017 01:23:33 PM CET, John Snow <js...@redhat.com> wrote: >> And of course another approach I already mentioned would be to scrap >> the overlap checks altogether once we have image locking (and I guess >> we can keep them around in their current form at least until then). > > I think it's worth having them. Perhaps if you use image locking they > can be disabled by default, but I wouldn't really advocate for > removing them. > > I think what you are pointing out with refcount blocks not being > essential to protect is probably pretty sufficient as an optimization, > too. Or I guess we can merge your ~real~ series to help optimize > things.
I think the overhead that most checks add is negligible, so I would not remove them. There are maybe three exceptions: - refcount-block: this one is slow even for small images, but I think it should be fine after my patch. - active-l2: this can be slow if the virtual size of the image is very large. It's still much faster than refcount-block and it can be made faster simply by increasing the cluster size (which makes sense for large images anyway). So I'm not too worried about it. - inactive-l2: this is probably the slowest of them all (it even involves reading from disk), but it's only used if there are internal snapshots. I haven't looked into this one. I think the checks as they are now are very simple and it's not worth complicating them too much unless we have numbers that prove that they're slowing things down. I only got those numbers for the first one. Berto
