From: Peter Xu <peterx@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Fabiano Rosas <farosas@suse.de>, qemu-devel@nongnu.org
Subject: Re: [PATCH] migration/multifd: Don't fsync when closing QIOChannelFile
Date: Wed, 6 Mar 2024 08:52:41 +0800 [thread overview]
Message-ID: <Zee-WYQg9c19Up-T@x1n> (raw)
In-Reply-To: <ZedbLT2pFNyRoX90@redhat.com>
On Tue, Mar 05, 2024 at 05:49:33PM +0000, Daniel P. Berrangé wrote:
> I don't think you should be removing this. Calling qio_channel_close()
> remains recommended best practice, even with fdatasync() removed, as
> it provides a strong guarantee that the FD is released which you don't
> get if you rely on the ref count being correctly decremented in all
> code paths.
Hmm, I have the confusion on why ioc->fd is more special than the ioc
itself when leaked. It'll be a bug anyway if we leak any of them? Leaking
fds may also help us to find such issue easier (e.g. by seeing stale fds
under /proc). From that POV I tend to agree on the original proposal.
Now we removed the data sync, IIUC it means the mgmt can always flush the
cache with/without the fd closed in QEMU even if it's leaked. So I don't
yet see other side effects of leaking the fd which will cause a difference
comparing to leaking the ioc?
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2024-03-06 0:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-05 17:43 [PATCH] migration/multifd: Don't fsync when closing QIOChannelFile Fabiano Rosas
2024-03-05 17:49 ` Daniel P. Berrangé
2024-03-06 0:52 ` Peter Xu [this message]
2024-03-06 9:25 ` Daniel P. Berrangé
2024-03-06 9:53 ` Peter Xu
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=Zee-WYQg9c19Up-T@x1n \
--to=peterx@redhat.com \
--cc=berrange@redhat.com \
--cc=farosas@suse.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.