All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Brian Foster <bfoster@redhat.com>,
	Dave Chinner <david@fromorbit.com>,
	linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: fix inode allocation block res calculation precedence
Date: Fri, 17 Jul 2020 13:07:26 -0700	[thread overview]
Message-ID: <20200717200726.GO3151642@magnolia> (raw)
In-Reply-To: <9e464b84-7945-95b5-c6ff-ae3eb8bee878@sandeen.net>

On Fri, Jul 17, 2020 at 10:16:02AM -0700, Eric Sandeen wrote:
> On 7/16/20 5:18 AM, Brian Foster wrote:
> > On Thu, Jul 16, 2020 at 12:02:09PM +1000, Dave Chinner wrote:
> 
> ...
> 
> >> i.e. XFS_IALLOC_SPACE_RES() is used in just 7 places in the code,
> >> 4 of them are in that same header file, so it's a simple, standalone
> >> patch that fixes the bug by addressing the underlying cause of
> >> the problem (i.e. nasty macro!).
> >>
> > I agree that the inline is nicer than the macro, but a transaction
> > reservation value seems misplaced to me in the IGEO. Perhaps having
> > something analogous to struct xfs_trans_resv might be more appropriate.
> 
> For whatever my opinion is worth these days, it seems like doing
> a survey to see how many of these reservations are static would be a
> good first step, and then decide where they should all go if they should
> move. I agree that IGEO might be a little odd, depending on what other
> static reservation types there are and what they're associated with.
> 
> I see both sides of the discussion re: how fixes like this move forward
> and what's easily backportable but in this case (and maybe I'm missing
> context) it seems like a wider survey would be wise before deciding to
> move this one value to IGEO in particular.

Agreed.  AFAICT the first patch is a bug fix for broken functionality,
so I will put it in the 5.9 branch update next week.

--D

> -Eric

  reply	other threads:[~2020-07-17 20:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15 19:33 [PATCH] xfs: fix inode allocation block res calculation precedence Brian Foster
2020-07-15 22:29 ` Dave Chinner
2020-07-16  1:47   ` Darrick J. Wong
2020-07-16  2:02     ` Dave Chinner
2020-07-16 12:18       ` Brian Foster
2020-07-17 17:16         ` Eric Sandeen
2020-07-17 20:07           ` Darrick J. Wong [this message]
2020-07-16 12:18 ` [PATCH 2/2] xfs: replace ialloc space res macro with inline helper Brian Foster
2020-07-16 22:01   ` Dave Chinner
2020-07-17 12:25     ` Brian Foster
2020-07-21 15:01 ` [PATCH] xfs: fix inode allocation block res calculation precedence Christoph Hellwig

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=20200717200726.GO3151642@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=bfoster@redhat.com \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /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.