From: Mark Syms <Mark.Syms@citrix.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH] gfs2: Prevent writeback in gfs2_file_write_iter
Date: Mon, 18 Mar 2019 15:10:19 +0000 [thread overview]
Message-ID: <b1cc8babcdb544d3a0342c1e4d0a545b@AMSPEX02CL02.citrite.net> (raw)
In-Reply-To: <CAHc6FU7d=hDgm7dikO4uJL5WQCu6r+F772c-dU_J50=qXmSLiw@mail.gmail.com>
-----Original Message-----
From: Andreas Gruenbacher <agruenba@redhat.com>
Sent: 17 March 2019 20:06
To: Mark Syms <Mark.Syms@citrix.com>
Cc: cluster-devel at redhat.com; Sergey Dyasli <sergey.dyasli@citrix.com>; Igor Druzhinin <igor.druzhinin@citrix.com>; Edvin Torok <edvin.torok@citrix.com>
Subject: Re: [Cluster-devel] [PATCH] gfs2: Prevent writeback in gfs2_file_write_iter
On Sun, 17 Mar 2019 at 00:59, Mark Syms <Mark.Syms@citrix.com> wrote:
>
> Sadly, this doesn't help and seems to make the situation worse. Our automated tests were previously seeing about 5% failure rate and with this patch its 20%.
So the PF_MEMALLOC flag doesn't get set on that code path. In that case, we should probably check wbc->sync_mode instead. How about the following?
diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c index 540535c..36de2f7 100644
--- a/fs/gfs2/super.c
+++ b/fs/gfs2/super.c
@@ -757,7 +757,7 @@ static int gfs2_write_inode(struct inode *inode, struct writeback_control *wbc)
bool flush_all = (wbc->sync_mode == WB_SYNC_ALL || gfs2_is_jdata(ip));
/* (see ext4_dirty_inode) */
- if (current->flags & PF_MEMALLOC)
+ if (wbc->sync_mode != WB_SYNC_ALL)
return 0;
if (flush_all)
It may help to wrap that condition in WARN_ON_ONCE for debugging.
[Mark Syms] That works better. We were wondering whether it might be a bit too aggressive though in that it skips writing the inode entirely unless we have WB_SYNC_ALL whereas the patch that Ross Lagerwall posted originally would use a trylock in the case where we don't have WB_SYNC_ALL and then fail out. Whether or not this should just silently return 0 or -EAGAIN as Ross' patch does is a matter of style I guess. What are your thoughts on this?
Thanks,
Mark.
next prev parent reply other threads:[~2019-03-18 15:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <19:84>
2019-03-16 23:58 ` [Cluster-devel] [PATCH] gfs2: Prevent writeback in gfs2_file_write_iter Mark Syms
2019-03-17 20:06 ` Andreas Gruenbacher
2019-03-18 15:10 ` Mark Syms [this message]
2019-03-18 16:30 ` Andreas Gruenbacher
2019-03-06 11:00 [Cluster-devel] GFS2 deadlock in 4.19 (iomap/writeback?) Edwin Török
2019-03-13 17:13 ` [Cluster-devel] [PATCH] gfs2: Prevent writeback in gfs2_file_write_iter Andreas Gruenbacher
2019-03-14 11:18 ` Ross Lagerwall
2019-03-15 20:58 ` Andreas Gruenbacher
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=b1cc8babcdb544d3a0342c1e4d0a545b@AMSPEX02CL02.citrite.net \
--to=mark.syms@citrix.com \
/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).