On 01/14/14 03:07, Qiao Nuohan wrote: > On 01/13/2014 06:39 PM, Laszlo Ersek wrote: >>>> >> >>>> >> - When this write_buffer() is directed to a regular file in >>>> non-flat >>>> >> mode, then the file might become sparse (you jump over a range of >>>> >> offsets with lseek() in write_buffer()). If the output has been >>>> opened >>>> >> by qemu itself (ie."file:....", in qmp_dump_guest_memory()), >>>> then due >>>> >> to the O_TRUNC we can't seek over preexistent data (and keep >>>> garbage in >>>> >> the file). When libvirt pre-opens the file (to send over the fd >>>> later), >>>> >> in doCoreDump(), it also passes O_TRUNC. OK. >>>> >> >>> > >>> > Do you mean because of O_TRUNC，seek will exceed the end of the file >>> > that may cause some problem? >> I meant that lseek() would seek over an unwritten portion of the file. >> If that portion had any kind of data written into it earlier, then that >> data would now likely turn into garbage (lose meaning, become truncated >> etc.) It wouldn't be corrupted or anything like that, it would just >> become a leftover with potential to cause misinterpretation. >> >> But, since we have O_TRUNC at open() time, we're seeking past the end of >> the file, and this sought-over portion will read back as zeroes (and the >> file might become "sparse", dependent on the filesystem and the size of >> the range sought-over). >> >> Seeking past the end of the file is explicitly allowed by POSIX: >> >> The lseek() function shall allow the file offset to be set beyond >> the end of the existing data in the file. If data is later written >> at this point, subsequent reads of data in the gap shall return >> bytes with the value 0 until data is actually written into the gap. >> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/lseek.html >> >> So this is fine. > > Thanks for your explanation. I think it would be better to abandon the > non-flat > mode to avoid potential risk.
I can't really provide any input to that decision -- I have no clue which tools support which format. The non-flat (ie. random-access, regular file) format appears more space- and computation-efficient, and I thought that would be the "natural" choice. The flat (non-seekable) format was a surprise to me -- I wouldn't have thought that any debugger could directly consume that format. So it's really your call. Again, the lseek()s seemed fine to me on POSIX platforms. Thanks, Laszlo
