Hi Ayal,

Thanks for the confirmation.  I guess a limitation of the current approach, is 
that there is no way to differentiate between retrying for transient errors 
(NFS error not responding) versus some other hard error that gets mapped to EIO 
(perhaps requiring real operator assistance).  Pretty much any unexpected error 
is mapped to EIO in the NFS stack.  Out of curiosity, does qemu retry all 
errors (ESTALE for example)?  That's one example of an irrecoverable error.

- ricardo

-----Original Message-----
From: Ayal Baron [mailto:aba...@redhat.com]
Sent: Sun 11/6/2011 1:19 AM
To: Labiaga, Ricardo
Cc: VDSM Project Development
Subject: EIO
Hi Ricardo,

During the workshop you asked about qemu behavior once resuming a VM after EIO.
I went back to check and qemu never passes the EIO to the guest, instead it 
retries the I/O.
So it would seem that the current behavior should be fine (also with soft 

Are there other error flows we should look into?
I seem to recall we discussed other issues as well, but I don't remember the 
specifics (jet lag).


vdsm-devel mailing list
  • EIO Ayal Baron
    • RE: EIO Labiaga, Ricardo

Reply via email to