Re: [Qemu-discuss] QImgError - find_allocation: Assertion `offs >= start' failed

[Fam Zheng]

On Tue, 01/09 23:18, Ala Hino wrote:
> qeum version:
> qemu-kvm-rhev-2.9.0-16.el7_4.5.x86_64
> 
> On Tue, Jan 9, 2018 at 11:10 PM, Ala Hino <address@hidden> wrote:
> 
> > Hello,
> >
> > A user is hitting the following error when performing `qemu-img commit`:
> >
> > 2018-01-03 09:48:54,168+0000 ERROR (tasks/5) [root] Job
> > u'e4d77997-db47-4c60-8f2c-019edebe9917' failed (jobs:217)
> > Traceback (most recent call last):
> >   File "/usr/lib/python2.7/site-packages/vdsm/jobs.py", line 154, in run
> >     self._run()
> >   File "/usr/share/vdsm/storage/sdm/api/merge.py", line 65, in _run
> >     self.operation.wait_for_completion()
> >   File "/usr/lib/python2.7/site-packages/vdsm/qemuimg.py", line 329, in
> > wait_for_completion
> >     self.poll(timeout)
> >   File "/usr/lib/python2.7/site-packages/vdsm/qemuimg.py", line 324, in
> > poll
> >     self.error)
> > QImgError: cmd=['/usr/bin/taskset', '--cpu-list', '0-31', '/usr/bin/nice',
> > '-n', '19', '/usr/bin/ionice', '-c', '3', '/usr/bin/qemu-img', 'commit',
> > '-p', '-t', 'none', '-b', u'/rhev/data-center/mnt/gluste
> > rSD/bms-gluster01-am5:_rhevm/ab27a13a-7a82-4cf4-86fd-3a6c69
> > 7ccef9/images/3122bbad-e3d3-446a-90b9-eb6da08dad2a/7fa44a9
> > 5-2988-4866-924c-329713989ad0', '-f', 'qcow2', u'/rhev/data-center/mnt/
> > glusterSD/bms-gluster01-am5:_rhevm/ab27a13a-7a82-4cf4-86fd-3a6c69
> > 7ccef9/images/3122bbad-e3d3-446a-90b9-eb6da08dad2a/8ba82ba
> > 8-32ea-4501-95e8-55ef42812c89'], ecode=-6, stdout=, stderr=qemu-img:
> > block/file-posix.c:1774: find_allocation: Assertion `offs >= start' failed.
> > , message=None
> >
> > Would appreciate any explanation of the error and what potentially could
> > cause it.

This is odd. The code around it is simply:

    off_t offs;

    /*
     * SEEK_DATA cases:
     * D1. offs == start: start is in data
     * D2. offs > start: start is in a hole, next data at offs
     * D3. offs < 0, errno = ENXIO: either start is in a trailing hole
     *                              or start is beyond EOF
     *     If the latter happens, the file has been truncated behind
     *     our back since we opened it.  All bets are off then.
     *     Treating like a trailing hole is simplest.
     * D4. offs < 0, errno != ENXIO: we learned nothing
     */
    offs = lseek(s->fd, start, SEEK_DATA);
    if (offs < 0) {
        return -errno;          /* D3 or D4 */
    }
    assert(offs >= start);

We already checked "offs < 0" so it is non-negative. But according to the
manpage:

>      SEEK_DATA
>             Adjust the file offset to the next location in the file greater
>             than or equal to offset containing data.  If offset points to
>             data, then the file offset is set to offset.

What is the filesystem the image is on? Maybe the implementation has violated
this and returned an offset before @start.

Can you run the qemu-img command manually and reproduce it? If you can please
collect the output after prepending to the command line with "strace -f -e
lseek", so we can see what the kernel has returned for the lseek call.

Fam