Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1511407 > unrolled thread

RE: [PATCH] Tools: hv: recover after hv_vss_daemon freeze times out

Started byKY Srinivasan <kys@microsoft.com>
First post2016-10-28 23:00 +0200
Last post2016-10-28 23:00 +0200
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  RE: [PATCH] Tools: hv: recover after hv_vss_daemon freeze times out KY Srinivasan <kys@microsoft.com> - 2016-10-28 23:00 +0200

#1511407 — RE: [PATCH] Tools: hv: recover after hv_vss_daemon freeze times out

FromKY Srinivasan <kys@microsoft.com>
Date2016-10-28 23:00 +0200
SubjectRE: [PATCH] Tools: hv: recover after hv_vss_daemon freeze times out
Message-ID<sxmpQ-4Re-29@gated-at.bofh.it>

> -----Original Message-----
> From: Michael Gissing [mailto:mg@faulpeltz.net]
> Sent: Thursday, October 13, 2016 2:27 PM
> To: Alex Ng (LIS) <alexng@microsoft.com>
> Cc: KY Srinivasan <kys@microsoft.com>; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> vkuznets@redhat.com; gregkh@linuxfoundation.org
> Subject: [PATCH] Tools: hv: recover after hv_vss_daemon freeze times out
> 
> 
> If a FIFREEZE operation run by the hv_vss_daemon takes longer than the
> VSS_USERSPACE_TIMEOUT set in the hv_snapshot module, instead of exiting
> after a write failure, try to recover by reopening the hv_vss device and
> performing the initial handshake again. Exiting causes all subsequent VSS
> operations sent by the Hyper-V host to fail until the daemon is restarted.
> 
> Signed-off-by: Michael Gissing <mg@faulpeltz.net>
> 
> ---
>   tools/hv/hv_vss_daemon.c | 11 ++++++++++-
>   1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
> index 5d51d6f..0ecbdab 100644
> --- a/tools/hv/hv_vss_daemon.c
> +++ b/tools/hv/hv_vss_daemon.c
> @@ -176,6 +176,7 @@ int main(int argc, char *argv[])
>       openlog("Hyper-V VSS", 0, LOG_USER);
>       syslog(LOG_INFO, "VSS starting; pid is:%d", getpid());
> 
> +recover:
>       vss_fd = open("/dev/vmbus/hv_vss", O_RDWR);
>       if (vss_fd < 0) {
>           syslog(LOG_ERR, "open /dev/vmbus/hv_vss failed; error: %d %s",
> @@ -196,6 +197,7 @@ int main(int argc, char *argv[])
>       }
> 
>       pfd.fd = vss_fd;
> +    in_handshake = 1;
> 
>       while (1) {
>           pfd.events = POLLIN;
> @@ -258,7 +260,14 @@ int main(int argc, char *argv[])
>           if (len != sizeof(struct hv_vss_msg)) {
>               syslog(LOG_ERR, "write failed; error: %d %s", errno,
>                      strerror(errno));
> -            exit(EXIT_FAILURE);
> +            /*
> +             * try to recover from possible timeout by THAWing
> +             * and restarting the message loop
> +            */
> +            vss_operate(VSS_OP_THAW);
> +            close(vss_fd);
> +            syslog(LOG_INFO, "trying to recover VSS connection");
> +            goto recover;
>           }
>       }

I agree with issuing a THAW command when we timeout in the kernel as this would leave
the file system in a sane state. That said, I am not sure why we need to close the fd and reinitialize
everything in the daemon. What if we just ignored the write error and go back to wait for new commands
from the host.

Regards,

K. Y  
> 
> --
> 2.7.4
> 

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web