cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
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.




  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).