All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Christoph Hellwig <hch@infradead.org>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: pass a commit_mode to xfs_trans_commit
Date: Fri, 1 May 2020 07:51:32 -0400	[thread overview]
Message-ID: <20200501115132.GG40250@bfoster> (raw)
In-Reply-To: <20200501104245.GA28237@lst.de>

On Fri, May 01, 2020 at 12:42:45PM +0200, Christoph Hellwig wrote:
> On Fri, May 01, 2020 at 06:24:03AM -0400, Brian Foster wrote:
> > I recall looking at this when it was first posted and my first reaction
> > was that I didn't really like the interface. I decided to think about it
> > to see if it grew on me and then just lost track (sorry). It's not so
> > much passing a flag to commit as opposed to the flags not directly
> > controlling behavior (i.e., one flag means sync if <something> is true,
> > another flag means sync if <something else> is true, etc.) tends to
> > confuse me. I don't feel terribly strongly about it if others prefer
> > this pattern, but I still find the existing code more readable.
> > 
> > I vaguely recall thinking it might be nice if we could dump this into
> > transaction state to avoid the aforementioned logic warts, but IIRC that
> > might not have been possible for all users of this functionality..
> 
> Moving the flag out of the transaction structure was the main motivation
> for this series - the fact that we need different arguments to
> xfs_trans_commit is just a fallout from that.  The rationale is that
> I found it highly confusing to figure out how and where we set the sync
> flag vs having it obvious in the one place where we commit the
> transaction.
> 

Sorry, I was referring to moving your new [W|DIR]SYNC variants to
somewhere like xfs_trans_res->tr_logflags in the comment above, not the
existing XFS_TRANS_SYNC flag (which I would keep). Regardless, I didn't
think that would work across the board from looking at it before.
Perhaps it would work in some cases..

I agree that the current approach is confusing in that it's not always
clear when to set the sync flag. I disagree that this patch makes it
obvious and in one place because when I see this:

	error = xfs_trans_commit(args->trans, XFS_TRANS_COMMIT_WSYNC);

... it makes me think the flag has an immediate effect (like COMMIT_SYNC
does) and subsequently raises the same questions around the existing
code of when or when not to use which flag in the context of the
individual transaction. *shrug* Just my .02.

Brian


  reply	other threads:[~2020-05-01 11:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-09  7:36 [PATCH] xfs: pass a commit_mode to xfs_trans_commit Christoph Hellwig
2020-05-01  8:07 ` Christoph Hellwig
2020-05-01 10:24   ` Brian Foster
2020-05-01 10:42     ` Christoph Hellwig
2020-05-01 11:51       ` Brian Foster [this message]
2020-05-01 15:53         ` Darrick J. Wong

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=20200501115132.GG40250@bfoster \
    --to=bfoster@redhat.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=linux-xfs@vger.kernel.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.