From: Zorro Lang <zlang@redhat.com>
To: Filipe Manana <fdmanana@kernel.org>
Cc: Su Yue <glass.su@suse.com>,
fstests@vger.kernel.org, linux-btrfs@vger.kernel.org,
l@damenly.org
Subject: Re: [PATCH] btrfs/172,206: call _log_writes_cleanup in _cleanup
Date: Sat, 2 Mar 2024 15:03:13 +0800 [thread overview]
Message-ID: <20240302070313.5tc5ylqpv6dyjgmf@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com> (raw)
In-Reply-To: <CAL3q7H53QTzMVdJwEJBOyoB3fBem-2zi3FH411JugRDkq9Bqvg@mail.gmail.com>
On Fri, Mar 01, 2024 at 02:55:26PM +0000, Filipe Manana wrote:
> On Fri, Mar 1, 2024 at 1:49 PM Zorro Lang <zlang@redhat.com> wrote:
> >
> > On Thu, Feb 15, 2024 at 10:02:36PM +0800, Su Yue wrote:
> > > From: Su Yue <glass.su@suse.com>
> > >
> > > Because block group tree requires require no-holes feature,
> > > _log_writes_mkfs "-O ^no-holes" fails when "-O block-group-tree" is
> > > given in MKFS_OPTION.
> > > Without explicit _log_writes_cleanup, the two tests fail with
> > > logwrites-test device left. And all next tests will fail due to
> > > SCRATCH DEVICE EBUSY.
> > >
> > > Fix it by overriding _cleanup to call _log_writes_cleanup.
> > >
> > > Signed-off-by: Su Yue <glass.su@suse.com>
> > > ---
> > > tests/btrfs/172 | 6 ++++++
> > > tests/btrfs/206 | 6 ++++++
> > > 2 files changed, 12 insertions(+)
> > >
> > > diff --git a/tests/btrfs/172 b/tests/btrfs/172
> > > index f5acc6982cd7..fceff56c9d37 100755
> > > --- a/tests/btrfs/172
> > > +++ b/tests/btrfs/172
> > > @@ -13,6 +13,12 @@
> > > . ./common/preamble
> > > _begin_fstest auto quick log replay recoveryloop
> > >
> > > +# Override the default cleanup function.
> > > +_cleanup()
> > > +{
> > > + _log_writes_cleanup &> /dev/null
> >
> > This _cleanup will override the default one, so better to copy the
> > default cleanup in this function,
> >
> > cd /
> > rm -r -f $tmp.*
>
> Zorro,
>
> You had already replied to v2 of this patch with exactly the same comments:
>
> https://lore.kernel.org/fstests/20240225162212.qcidpyb2bhdburl6@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com/
Hi Filipe,
Oh, sorry for this duplicated review, I tried to scan the email list to
make sure I didn't miss something.
>
> It's trivial to do those changes.
> Do you expect Su to send yet another version just for that, or could
> you amend the patch?
I expect to get a simple response from the author, for his patch.
E.g.:
1) "Yes, agree, could you help to change that when you merge it?"
2) "No, I think it doesn't make sense"
3) "Sure, I'll make a bit change in next version"
4) "Oh, that reminds me, I should cleanup more, I think I can change more about that"
...
Is that hard?
If the author doesn't have any opinions, just asks for the amending from me,
I'll do that if there's not risk. Or I suppose the author always hope to change
his code by himself, maybe not follow the review points 100%.
>
> Can you please be more clear in future replies about that, i.e. if you
> expect the author to send a new version or if you'll amend the patch
> for trivial changes?
You think it's trivial, due to you think you don't need more changes about
that. But I'm not sure before you say that. You can check the list, I say
"I'll help to change that when I merge it", but just when I'm sure it's clear
enough. You shouldn't use your measure to think my standard.
I didn't say I'll amend that means my review point is a reference, to check
if you have more ideas.
We just got a big regression in a _cleanup function which does:
cd /
rm -r -f $tmp.*
specific_xxxx_cleanup
Then that specific_xxxx_cleanup() remove all things in "/".
If it's
specific_xxxx_cleanup
cd /
rm -r -f $tmp.*
things might be different or not.
I'm not saying that change must makes differences. But the cleanup things
(e.g. theorder of the steps) might worth a bit evaluating, not just changed
by myself without any response. And a reply from the author to the review
points of his patch is not hard. Even just say "yes, please help that",
that means you reviewed and agreed my review points at least.
I'm not anyone else. Each one has his distinctive style. I don't know what's
wrong with that way to deal with patches, to make you such unsatisfied. It is
difficult to cater to all tastes.
Thanks,
Zorro
>
> Speaking for myself, I very often get confused with your replies, and
> I feel that some patches often get stalled for that reason.
> Usually with Eryu or Dave that didn't happen, the course of action was clear.
>
> Thanks.
>
> >
> > You can refer to btrfs/196 or generic/482 etc.
> >
> > > +}
> > > +
> > > # Import common functions.
> > > . ./common/filter
> > > . ./common/dmlogwrites
> > > diff --git a/tests/btrfs/206 b/tests/btrfs/206
> > > index f6571649076f..e05adf75b67e 100755
> > > --- a/tests/btrfs/206
> > > +++ b/tests/btrfs/206
> > > @@ -14,6 +14,12 @@
> > > . ./common/preamble
> > > _begin_fstest auto quick log replay recoveryloop punch prealloc
> > >
> > > +# Override the default cleanup function.
> > > +_cleanup()
> > > +{
> > > + _log_writes_cleanup &> /dev/null
> >
> >
> > Same as above.
> >
> > Thanks,
> > Zorro
> >
> > > +}
> > > +
> > > # Import common functions.
> > > . ./common/filter
> > > . ./common/dmlogwrites
> > > --
> > > 2.43.0
> > >
> > >
> >
> >
>
prev parent reply other threads:[~2024-03-02 7:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-15 14:02 [PATCH] btrfs/172,206: call _log_writes_cleanup in _cleanup Su Yue
2024-02-15 15:58 ` Filipe Manana
2024-02-15 23:10 ` Qu Wenruo
2024-03-01 13:49 ` Zorro Lang
2024-03-01 14:55 ` Filipe Manana
2024-03-02 7:03 ` Zorro Lang [this message]
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=20240302070313.5tc5ylqpv6dyjgmf@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com \
--to=zlang@redhat.com \
--cc=fdmanana@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=glass.su@suse.com \
--cc=l@damenly.org \
--cc=linux-btrfs@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 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 read-only IMAP folder(s) and NNTP newsgroup(s).