From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Justin Ossevoort <justin@quarantainenet.nl>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v4 0/2] Fix guest-fstrim behaviour
Date: Mon, 06 Jul 2015 20:32:47 -0500 [thread overview]
Message-ID: <20150707013247.17393.19280@loki> (raw)
In-Reply-To: <1431327525-25625-1-git-send-email-justin@quarantainenet.nl>
Quoting Justin Ossevoort (2015-05-11 01:58:43)
> The qemu-ga 'guest-fstrim' command is currently not working properly.
>
> There are 2 issues:
> - The current implementation reuses a struct between ioctl() calls without
> reinitialising it's fields. This struct however is updated to reflect
> the result of the trim operation.
> Therefor only the first filesystem is thoroughly trimmed, the rest is only
> trimmed up to the amount that was trimmed by the previous filesystem.
> - The current implementation will return an error if some filesystem returned
> an unexpected error. The first issue consistently causes this issue when
> the 'guest-fstrim' is performed multiple times in a row when multiple
> filesystems are being trimmed, as this causes a trim request for at most
> 0 bytes, which is an error.
Applied, thanks.
>
> The first patch fixes the first issue by explicitly resetting the struct used
> to perform the trim ioctl for each path. This is a pretty mundane change and
> fixes most use-cases.
>
> The second patch fixes the second issue by changing the returned value to
> return a per-path result. This way all paths are always trimmed and dependening
> on the outcome of the ioctl an error or some details about the trim are
> returned. The returned values for error, minimum and trimmed are filesystem,
> storage stack and kernel version dependant.
>
> There was an earlier request to mirror the fields from the 'guest-fsinfo'
> operation. The trim operation however need not happen at the mountpoint level.
> A logical future improvement would be to allow the caller to supply an optional
> list of paths they want to trim, without needing to have intimate details about
> the filesystem layout of the guest.
>
> [Changes since v3]
> - Patch 2: Change return type of qmp_guest_fstrim in qga/command-win32.c
> - Patch 2: Change commit message on patch 2 to indicate returned values are
> filesystem, storage stack and kernel version dependant
>
> Justin Ossevoort (2):
> qga/commands-posix: Fix bug in guest-fstrim
> qga/commands-posix: Return per path fstrim result
>
> qga/commands-posix.c | 63 ++++++++++++++++++++++++++++++++++++----------------
> qga/commands-win32.c | 4 +++-
> qga/qapi-schema.json | 32 +++++++++++++++++++++++---
> 3 files changed, 76 insertions(+), 23 deletions(-)
>
> --
> 2.1.4
>
>
prev parent reply other threads:[~2015-07-07 1:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-11 6:58 [Qemu-devel] [PATCH v4 0/2] Fix guest-fstrim behaviour Justin Ossevoort
2015-05-11 6:58 ` [Qemu-devel] [PATCH v4 1/2] qga/commands-posix: Fix bug in guest-fstrim Justin Ossevoort
2015-05-26 18:54 ` Thomas Huth
2015-05-27 0:50 ` Michael Roth
2015-05-11 6:58 ` [Qemu-devel] [PATCH v4 2/2] qga/qmp_guest_fstrim: Return per path fstrim result Justin Ossevoort
2015-05-25 10:41 ` Olga Krishtal
2015-05-27 1:20 ` Michael Roth
2015-05-27 4:13 ` Michael Roth
2015-05-27 4:25 ` Eric Blake
2015-07-07 1:32 ` Michael Roth [this message]
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=20150707013247.17393.19280@loki \
--to=mdroth@linux.vnet.ibm.com \
--cc=justin@quarantainenet.nl \
--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).