All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: Filipe Manana <fdmanana@kernel.org>
Cc: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 3/3] btrfs: test mount fails on physical device with configured dm volume
Date: Fri, 8 Mar 2024 19:05:11 +0530	[thread overview]
Message-ID: <290e74fe-d199-4c8c-bf02-f7003232dad9@oracle.com> (raw)
In-Reply-To: <CAL3q7H4HV-UBd9hEKB1+isH2H4TThsx0DnvfYxsY+=BB64PqqA@mail.gmail.com>



On 3/8/24 18:00, Filipe Manana wrote:
> On Thu, Mar 7, 2024 at 4:46 PM Anand Jain <anand.jain@oracle.com> wrote:
>>
>>
>>> I'm also not convinced that we need this test, because the bug could
>>> be reliably reproduced by running all existing tests or just a subset
>>> of the tests as I reported there.
>>
>> This test case was motivated by btrfs/159; and recent report;
>> yep, most of the lines here are taken from btrfs/159.
> 
> Ok, so it's motivated by what I reported, triggered by btrfs/159 but
> only when other tests are run before it.
> 
>> However, I wanted a test case in the tempfsid group which
>> exercises multi-node-same-physical;
> 
> Sure. It's just that we could trigger the issue simply by running all
> existing tests, or just a subset as I reported before [1].
> It was fully deterministic and David could reproduce it after the report too.
> 
> What surprises me is that no one noticed this before and at some stage
> the faulty patch was about to be sent to Linus.
> 
>>
>> If there are no objections, I am going to add the tempfsid group to
>> btrfs/159 for now.
> 
> That is confusing, please don't.
> btrfs/159 doesn't test tempfsid, it existed for many years before the
> tempfsid feature (introduced in the 6.7 kernel),
> it just happens that it triggers the issue if other fstests are run before it.
> 
> That would also be pointless because running btrfs/159 alone doesn't
> trigger the bug, so running "./check -g tempfsid" wouldn't cause 159
> to fail.
> 
> Between that and a new test case that is somewhat redundant, I'd
> rather have the new test case with proper documentation/comments.
> 

I have converted this test case into a generic one. Now, XFS, ext4,
and Btrfs (after a patch) match the golden output. I'll be sending
the btrfs kernel patch along with it.

Thanks, Anand


> Thanks.
> 
> [1] https://lore.kernel.org/linux-btrfs/CAL3q7H5wx5rKmSzGWP7mRqaSfAY88g=35N4OBrbJB61rK0mt2w@mail.gmail.com/
> 
>>
>> Thanks, Anand

  reply	other threads:[~2024-03-08 13:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1709806478.git.anand.jain@oracle.com>
2024-03-07 12:50 ` [PATCH 1/3] .gitignore: add src/fcntl_lock_corner_tests Anand Jain
2024-03-07 15:26   ` Zorro Lang
2024-03-07 15:55     ` Anand Jain
2024-03-07 12:50 ` [PATCH 2/3] common/rc: specify required device size Anand Jain
2024-03-07 15:16   ` Zorro Lang
2024-03-07 16:08     ` Anand Jain
2024-03-07 12:50 ` [PATCH 3/3] btrfs: test mount fails on physical device with configured dm volume Anand Jain
2024-03-07 14:59   ` Zorro Lang
2024-03-07 16:15   ` Filipe Manana
2024-03-07 16:46     ` Anand Jain
2024-03-08 12:30       ` Filipe Manana
2024-03-08 13:35         ` Anand Jain [this message]
2024-03-07 19:20   ` Zorro Lang
2024-03-08 13:38     ` Anand Jain

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=290e74fe-d199-4c8c-bf02-f7003232dad9@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=fdmanana@kernel.org \
    --cc=fstests@vger.kernel.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 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.