qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] hd-geo-test failing on OpenIndiana


From: Markus Armbruster
Subject: Re: [Qemu-devel] hd-geo-test failing on OpenIndiana
Date: Mon, 28 Jan 2013 08:53:49 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

Andreas Färber <address@hidden> writes:

> Hello Markus,
>
> On OpenIndiana 151a7 I am seeing assertion failures for ret == 0 in
> hd-geo-test.c:35:create_test_img(). It seems it is refusing to blow up
> the temporary file. Any suggestion what to do about that?

Fine print on ftruncate():

    If fildes refers to a regular file, the ftruncate() function shall
    cause the size of the file to be truncated to length.  If the size
    of the file previously exceeded length, the extra data shall no
    longer be available to reads on the file.  If the file previously
    was smaller than this size, ftruncate() shall either increase the
    size of the file or fail.  XSI-conformant systems shall increase the
    size of the file.  If the file size is increased, the extended area
    shall appear as if it were zero-filled. The value of the seek
    pointer shall not be modified by a call to ftruncate().

Looks like OpenIndiana got stuck in the 20th century.

If you care for such losing systems, you need create_test_img to fall
back or switch wholesale to a less elegant way to create the image.

Unfortunately, what ftruncate() returns on failure to extend

    [EFBIG] or [EINVAL]
        The length argument was greater than the maximum file size.

can mean plenty of other things, too:
    
    [EINVAL]
        The length argument was less than 0.
    [EFBIG]
        The file is a regular file and length is greater than the offset
        maximum established in the open file description associated with
        fildes.
    [EINVAL]
        The fildes argument references a file that was opened without
        write permission.

Could mean falling back is not practical.

Switching to a full write() of the image is not advised, though, because
the large image has 8388608 sectors (4GiB).  You really want to create a
sparse file.



reply via email to

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