From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2tkl-0008Cz-U2 for qemu-devel@nongnu.org; Mon, 13 Jan 2014 21:29:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2tkh-00007G-D6 for qemu-devel@nongnu.org; Mon, 13 Jan 2014 21:29:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47578) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2tkh-00006c-5O for qemu-devel@nongnu.org; Mon, 13 Jan 2014 21:29:15 -0500 Message-ID: <52D4A0F1.80405@redhat.com> Date: Tue, 14 Jan 2014 03:29:05 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1388906864-1083-1-git-send-email-qiaonuohan@cn.fujitsu.com> <1388906864-1083-7-git-send-email-qiaonuohan@cn.fujitsu.com> <52CBE72E.9070805@redhat.com> <52D3B9F6.3070804@cn.fujitsu.com> <52D3C27A.8040403@redhat.com> <52D49BD5.2070903@cn.fujitsu.com> In-Reply-To: <52D49BD5.2070903@cn.fujitsu.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v6 06/11] dump: add API to write dump header List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Qiao Nuohan Cc: stefanha@gmail.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, anderson@redhat.com, kumagai-atsushi@mxc.nes.nec.co.jp, akong@redhat.com, afaerber@suse.de 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 o= f >>>> >> 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=EF=BC=8Cseek 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 tha= t >> data would now likely turn into garbage (lose meaning, become truncate= d >> 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 t= he >> file might become "sparse", dependent on the filesystem and the size o= f >> 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 writte= n >> at this point, subsequent reads of data in the gap shall return >> bytes with the value 0 until data is actually written into the ga= p. >> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/lseek.html >> >> So this is fine. >=20 > 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