[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v6 06/11] dump: add API to write dump header

From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH v6 06/11] dump: add API to write dump header
Date: Tue, 14 Jan 2014 03:29:05 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]