On Wed, Dec 02, 2015 at 09:01:16AM -0700, Eric Blake wrote: > On 12/02/2015 08:21 AM, Peter Xu wrote: > > Will the raw memory total size useful in any way? I am totally ok to > > add this, just failed to find a way for user to use it besides > > calculating finished work during dump... :( > > Good idea. You never know if it will be helpful, but the information is > basically free to provide and doesn't seem like too much of a > maintenance burden to promise to always include the total. And in the > case of an error, knowing the final values of complete/total might also > be useful to see how far things got before failure (for example, if it > failed because of ENOSPACE, knowing how much was complete may give an > idea of how much additional space should be added before retrying).
Yes, it's more meaningful when it fails. And maybe you are right, it's free to provide it. :) I can add it in v5. One thing to mention is that, since the written_byte field is only for raw memory size, which means (e.g., for kdump-zlib), the number could first goes to 70% of total very quickly in less than a second (possibly due to zero pages, so actually very little data is written to disk), then it will use another ten seconds to finish the rest 30% (which contains most of the data of the final dump file). So the number would still help little even with ENOSPACE. When user sees a 70% of "written" when failed, it will not mean "we need extra of 30% more spaces", it actually means "we need 100% more", but the user would never figure out the real situation from the number only. :( Thanks! Peter > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >
