qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] qcow2_open ignores EAGAIN


From: Kevin Wolf
Subject: Re: [Qemu-block] qcow2_open ignores EAGAIN
Date: Thu, 19 Apr 2018 12:26:53 +0200
User-agent: Mutt/1.9.1 (2017-09-22)

Am 19.04.2018 um 11:58 hat Olaf Hering geschrieben:
> Am Thu, 19 Apr 2018 11:50:33 +0200
> schrieb Kevin Wolf <address@hidden>:
> 
> > The real question is why somebody else still holds a lock.
> 
> Since it is shared the other host may not be quick enough to release it.
> Or this host just did not see the event yet.

qemu releases the lock before it completes migration, so in theory that
shouldn't happen. Unless somehow the information about the released lock
is propagated only with a delay - but if so, how long should we wait
until we decide that the other party probably isn't going to release
their lock anytime soon?

What kind of shared storage is this? And can you verify if the source
host really gives up the lock if you give it a few more seconds? (Just
starting another qemu process that uses the image should be enough to
check.)

I see Xen in function names and suspect that Xen migration simply
doesn't correctly inactivate images on the source or activate them on
the destination. I seem to remember that it uses a separate
implementation for migration completion.

> So are you saying -EAGAIN is a hard error, despite the name?

At least "hard" as in "the error cause isn't guaranteed to go away in
very short time". It's not hard in the sense that the condition _may_ go
away, but it may also last indefinitely. We can't predict it.

Kevin

Attachment: signature.asc
Description: PGP signature


reply via email to

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