From: Alli <allison.henderson@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <djwong@kernel.org>, linux-xfs@vger.kernel.org
Subject: Re: [5.19 cycle] Planning and goals
Date: Mon, 11 Apr 2022 12:38:05 -0700 [thread overview]
Message-ID: <36ff0be52e2eef856dab403bdc76602e403d74c8.camel@oracle.com> (raw)
In-Reply-To: <20220411035935.GZ1544202@dread.disaster.area>
On Mon, 2022-04-11 at 13:59 +1000, Dave Chinner wrote:
> On Mon, Apr 11, 2022 at 11:50:23AM +1000, Dave Chinner wrote:
> > On Thu, Apr 07, 2022 at 03:40:08PM -0700, Alli wrote:
> > > On Thu, 2022-04-07 at 15:49 +1000, Dave Chinner wrote:
> > > > On Wed, Apr 06, 2022 at 08:11:06PM -0700, Darrick J. Wong
> > > > wrote:
> > > > > On Tue, Apr 05, 2022 at 12:03:12PM +1000, Dave Chinner wrote:
> > > > > > - Logged attributes V28 (Allison)
> > > > > > - I haven't looked at this since V24, so I'm not sure
> > > > > > what
> > > > > > the current status is. I will do that discovery later
> > > > > > in
> > > > > > the week.
> > > > > > - Merge criteria and status:
> > > > > > - review complete: Not sure
> > > So far each patch in v29 has at least 2 rvbs I think
> >
> > OK.
> >
> > > > > > - no regressions when not enabled: v24 was OK
> > > > > > - no major regressions when enabled: v24 had
> > > > > > issues
> > > > > > - Open questions:
> > > > > > - not sure what review will uncover
> > > > > > - don't know what problems testing will show
> > > > > > - what other log fixes does it depend on?
> > > If it goes on top of whiteouts, it will need some modifications
> > > to
> > > follow the new log item changes that the whiteout set makes.
> > >
> > > Alternately, if the white out set goes in after the larp set,
> > > then it
> > > will need to apply the new log item changes to xfs_attr_item.c as
> > > well
> >
> > I figured as much, thanks for confirming!
Hi Dave, sorry I just noticed this response after I had sent out the
whiteout reviews last night
>
> Ok, so I've just gone through the process of merging the two
> branches to see where we stand. The modifications to the log code
> that are needed for the larp code - changes to log iovec processing
> and padding - are out of date in the LARP v29 patchset.
>
> That is, the versions that are in the intent whiteout patchset are
> much more sophisticated and cleanly separated. The version of the
> "avoid extra transactions when no intents" patch in the LARP v29
> series is really only looking at whether the transaction is dirty,
> not whether there are intents in the transactions, which is what we
> really need to know when deciding whether to commit the transaction
> or not.
Ok, so it sounds like patch 2 of the larp set needs to be dropped then
>
> There are also a bunch of log iovec changes buried in patch 4 of the
> LARP patchset which is labelled as "infrastructure". Those changes
> are cleanly split out as patch 1 in the intent whiteout patchset and
> provide the xlog_calc_vec_len() function that the LARP code needs.
>
Ok, I will see if I can separate those out then
> As such, the RVBs on the patches in the LARPv29 series don't carry
> over to the patches in the intent whiteout series - they are just
> too different for that to occur.
>
> The additional changes needed to support intent whiteouts are
> relatively straight forward for the attri/attrd items, so at this
> point I'd much prefer that the two patchsets are ordered "intent
> whiteouts" then "LARP".
Alrighty then, sounds good.
>
> I've pushed the compose I just processed to get most of the pending
> patchsets as they stand into topic branches and onto test machines
> out to kernel.org. Have a look at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git xfs-
> 5.19-compose
Ok, I will take a look at this, I had not noticed it last night
>
> to see how I merged everything and maybe give it a run through your
> test cycle to see if there's anything I broke when LARP is
> enabled....
Great, thanks!
Allison
>
> Cheers,
>
> Dave.
next prev parent reply other threads:[~2022-04-11 19:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 2:03 [5.19 cycle] Planning and goals Dave Chinner
2022-04-07 3:11 ` Darrick J. Wong
2022-04-07 5:49 ` Dave Chinner
2022-04-07 22:40 ` Alli
2022-04-11 1:50 ` Dave Chinner
2022-04-11 3:59 ` Dave Chinner
2022-04-11 7:31 ` Dave Chinner
2022-04-11 8:50 ` Dave Chinner
2022-04-11 20:00 ` Alli
2022-04-11 19:38 ` Alli [this message]
2022-04-10 18:21 ` Darrick J. Wong
2022-04-11 1:51 ` Dave Chinner
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=36ff0be52e2eef856dab403bdc76602e403d74c8.camel@oracle.com \
--to=allison.henderson@oracle.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--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.