qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: qemu-devel@nongnu.org
Cc: mdroth@linux.vnet.ibm.com, Justin Ossevoort <justin@quarantainenet.nl>
Subject: Re: [Qemu-devel] [PATCH v3 2/2] qga/commands-posix: Return per path fstrim result
Date: Thu, 30 Apr 2015 18:35:40 +0200	[thread overview]
Message-ID: <20150430183540.3c78a19b@thh440s> (raw)
In-Reply-To: <1430404198-10324-3-git-send-email-justin@quarantainenet.nl>

On Thu, 30 Apr 2015 16:29:58 +0200
Justin Ossevoort <justin@quarantainenet.nl> wrote:

> The current guest-fstrim support only returns an error if some
> mountpoint was unable to be trimmed, skipping any possible additional
> mountpoints. The result of the TRIM operation itself is also discarded.
> 
> This change returns a per mountpoint result of the TRIM operation. If an
> error occurs on some mountpoints that error is returned and the
> guest-fstrim continue with any additional mountpoints.
> 
> Signed-off-by: Justin Ossevoort <justin@quarantainenet.nl>
> ---
>  qga/commands-posix.c | 54 ++++++++++++++++++++++++++++++++++++++--------------
>  qga/qapi-schema.json | 32 ++++++++++++++++++++++++++++---
>  2 files changed, 69 insertions(+), 17 deletions(-)
> 
> diff --git a/qga/commands-posix.c b/qga/commands-posix.c
> index 4449628..ec0d69e 100644
> --- a/qga/commands-posix.c
> +++ b/qga/commands-posix.c
> @@ -1325,8 +1325,12 @@ static void guest_fsfreeze_cleanup(void)
>  /*
>   * Walk list of mounted file systems in the guest, and trim them.
>   */
> -void qmp_guest_fstrim(bool has_minimum, int64_t minimum, Error **errp)
> +GuestFilesystemTrimResponse *
> +qmp_guest_fstrim(bool has_minimum, int64_t minimum, Error **errp)
>  {
> +    GuestFilesystemTrimResponse *response;
> +    GuestFilesystemTrimResultList *list;
> +    GuestFilesystemTrimResult *result;
>      int ret = 0;
>      FsMountList mounts;
>      struct FsMount *mount;
> @@ -1340,39 +1344,59 @@ void qmp_guest_fstrim(bool has_minimum, int64_t minimum, Error **errp)
>      build_fs_mount_list(&mounts, &local_err);
>      if (local_err) {
>          error_propagate(errp, local_err);
> -        return;
> +        return NULL;
>      }
>  
> +    response = g_malloc0(sizeof(*response));
> +
>      QTAILQ_FOREACH(mount, &mounts, next) {
> +        result = g_malloc0(sizeof(*result));
> +        result->path = g_strdup(mount->dirname);
> +
> +        list = g_malloc0(sizeof(*list));
> +        list->value = result;
> +        list->next = response->paths;
> +        response->paths = list;
> +
>          fd = qemu_open(mount->dirname, O_RDONLY);
>          if (fd == -1) {
> -            error_setg_errno(errp, errno, "failed to open %s", mount->dirname);
> -            goto error;
> +            result->error = g_strdup_printf("failed to open: %s",
> +                                            strerror(errno));
> +            result->has_error = true;
> +            continue;
>          }
>  
>          /* We try to cull filesytems we know won't work in advance, but other
>           * filesytems may not implement fstrim for less obvious reasons.  These
> -         * will report EOPNOTSUPP; we simply ignore these errors.  Any other
> -         * error means an unexpected error, so return it in those cases.  In
> -         * some other cases ENOTTY will be reported (e.g. CD-ROMs).
> +         * will report EOPNOTSUPP; while in some other cases ENOTTY will be
> +         * reported (e.g. CD-ROMs).
> +         * Any other error means an unexpected error.
>           */
>          r.start = 0;
>          r.len = -1;
>          r.minlen = has_minimum ? minimum : 0;
>          ret = ioctl(fd, FITRIM, &r);
>          if (ret == -1) {
> -            if (errno != ENOTTY && errno != EOPNOTSUPP) {
> -                error_setg_errno(errp, errno, "failed to trim %s",
> -                                 mount->dirname);
> -                close(fd);
> -                goto error;
> +            result->has_error = true;
> +            if (errno == ENOTTY || errno == EOPNOTSUPP) {
> +                result->error = g_strdup("trim not supported");
> +            } else {
> +                result->error = g_strdup_printf("failed to trim: %s",
> +                                                strerror(errno));
>              }
> +            close(fd);
> +            continue;
>          }
> +
> +        result->has_minimum = true;
> +        result->minimum = r.minlen;

I'm not sure, but does this "minimum" result make sense at all? What's
the kernel supposed to return in this field? I had a quick look at some
file system implementations in the kernel, but to me it seems like only
the .len field is updated with a return value.

> +        result->has_trimmed = true;
> +        result->trimmed = r.len;
>          close(fd);
>      }
>  
> -error:
>      free_fs_mount_list(&mounts);
> +    return response;
>  }
>  #endif /* CONFIG_FSTRIM */

I just also had a quick test of this patch and got this behaviour:

{"execute":"guest-fstrim"}            
{"return": {"paths": [{"minimum": 4096, "path": "/mnt", "trimmed": 2040348672}, {"minimum": 4096, "path": "/mnt2", "trimmed": 2040348672}, {"minimum": 0, "path": "/boot", "trimmed": 388968448}, {"minimum": 0, "path": "/", "trimmed": 17699807232}]}}
{"execute":"guest-fstrim"}            
{"return": {"paths": [{"minimum": 4096, "path": "/mnt", "trimmed": 0}, {"minimum": 4096, "path": "/mnt2", "trimmed": 0}, {"minimum": 0, "path": "/boot", "trimmed": 388968448}, {"minimum": 0, "path": "/", "trimmed": 17699799040}]}}
{"execute":"guest-fstrim"}            
{"return": {"paths": [{"minimum": 4096, "path": "/mnt", "trimmed": 0}, {"minimum": 4096, "path": "/mnt2", "trimmed": 0}, {"minimum": 0, "path": "/boot", "trimmed": 388968448}, {"minimum": 0, "path": "/", "trimmed": 17699799040}]}}
{"execute":"guest-fstrim"}            
{"return": {"paths": [{"minimum": 4096, "path": "/mnt", "trimmed": 0}, {"minimum": 4096, "path": "/mnt2", "trimmed": 0}, {"minimum": 0, "path": "/boot", "trimmed": 388968448}, {"minimum": 0, "path": "/", "trimmed": 17699799040}]}}
{"execute":"guest-fstrim"}            
{"return": {"paths": [{"minimum": 4096, "path": "/mnt", "trimmed": 0}, {"minimum": 4096, "path": "/mnt2", "trimmed": 0}, {"minimum": 0, "path": "/boot", "trimmed": 388968448}, {"minimum": 0, "path": "/", "trimmed": 17699799040}]}}

/mnt and /mnt2 got successfully trimmed and consecutive calls then
reported "trimmed: 0". But the values for "/boot" and "/" do not make
sense to me, why does it claim to have always trimmed the same amount
of bytes here? (I only touched the /mnt and /mnt2 file systems before
doing the trim calls, so I wonder why there are bytes trimmed on /
and /boot at all?)

Also, I think you need to adjust the stub of qmp_guest_fstrim() in
commands-win32.c, too, so that you don't break the compilation of the
windows target.

 Thomas

  reply	other threads:[~2015-04-30 16:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-30 14:29 [Qemu-devel] [PATCH v3 0/2] Fix guest-fstrim behaviour Justin Ossevoort
2015-04-30 14:29 ` [Qemu-devel] [PATCH v3 1/2] qga/commands-posix: Fix bug in guest-fstrim Justin Ossevoort
2015-04-30 14:45   ` Thomas Huth
2015-04-30 14:29 ` [Qemu-devel] [PATCH v3 2/2] qga/commands-posix: Return per path fstrim result Justin Ossevoort
2015-04-30 16:35   ` Thomas Huth [this message]
2015-05-01 11:56     ` Justin Ossevoort

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150430183540.3c78a19b@thh440s \
    --to=thuth@redhat.com \
    --cc=justin@quarantainenet.nl \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).