All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zorro Lang <zlang@kernel.org>
To: Qu Wenruo <wqu@suse.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	fstests@vger.kernel.org,  linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] fstests: generic/362: remove the old file to reflect new mount options
Date: Fri, 29 May 2026 17:02:42 +0800	[thread overview]
Message-ID: <ahlU702Bo_QRTCCY@zlang-mailbox> (raw)
In-Reply-To: <bea8a50b-4a14-4351-a56a-d295b90750b5@suse.com>

On Thu, May 28, 2026 at 07:12:24AM +0930, Qu Wenruo wrote:
> 
> 
> 在 2026/5/27 22:33, Christoph Hellwig 写道:
> > On Wed, May 27, 2026 at 04:20:38PM +0930, Qu Wenruo wrote:
> > > > I'd rather add a copy of the test that runs on the scratch device
> > > > that can control the environment.  Or maybe just change the test
> > > > to use the scratch device?
> > > 
> > > I'm completely happy with using scratch device instead of test dev.
> > > 
> > > If no special reason to use test dev, the next update will go scratch dev
> > > instead.
> > 
> > I went back and re-read this.  What is the special mount option you
> > change?   If you want to always exercise this as nocow, maybe add a new
> > btrfs test that is a copy and uses the scratch device?  Or am I
> > misunderstanding something?
> > 
> 
> My point is, the current script prevent the test case to respect certain
> mount options, thus reduce the coverage.
> 
> E.g. in a multi-section fstests setup, default and nodatasum mount options
> are defined in different sections, and default mount option will be run
> first.
> 
> Then the next nodatasum section will still utilize the old inode created
> with regular default options, thus reduce the coverage.
> 
> 
> Sure, a dedicated btrfs copy will help, but that will introduce duplication.
> Not sure what is the proper way to handle such situation.

If there is a specific btrfs bug (commit) that can be 100% reproduced by
slightly modifying this case (e.g. use a specific mkfs or mount option),
I think it’s worth splitting it into a separate test case for better
test coverage and known issue tracking.

Thanks,
Zorro

> 
> 
> For now I'll follow Filipe's review to use _cleanup() to delete those
> involves test cases.
> 
> Thanks,
> Qu
> 

  reply	other threads:[~2026-05-29  9:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26  7:00 [PATCH] fstests: generic/362: remove the old file to reflect new mount options Qu Wenruo
2026-05-27  6:34 ` Christoph Hellwig
2026-05-27  6:50   ` Qu Wenruo
2026-05-27 13:03     ` Christoph Hellwig
2026-05-27 21:42       ` Qu Wenruo
2026-05-29  9:02         ` Zorro Lang [this message]
2026-05-27 14:26 ` Filipe Manana

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=ahlU702Bo_QRTCCY@zlang-mailbox \
    --to=zlang@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.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 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.