On Tue 16 Jan 2018 11:42:45 PM CET, Eric Blake wrote: > Callers like 'qemu-img map' will potentially have to iterate in more > steps over an entire image; but that's not a severe limitation. The > block_status() functions already document that as long as drivers make > progress, callers must be prepared for back-to-back calls that return > the same status, so you are not breaking semantics with a shorter > clamping limit. > > Maybe some of that is worth mentioning in the commit message. Either > way,
Yes indeed, for 4KB slices and 64KB clusters each slice can only map 32MB. Then again I don't think that it makes sense to change the slice size for qemu-img map, or in general for anything that does pure sequential I/O. But it's probably worth mentioning in the commit message. Berto
