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 mounts). 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). Regards, Ayal.
_______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
