All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Anand Jain <anand.jain@oracle.com>
Cc: linux-btrfs@vger.kernel.org, dsterba@suse.com
Subject: Re: [PATCH 4/4] btrfs-progs: test btrfstune -m|M ability to fix previous failures
Date: Tue, 3 Oct 2023 19:36:36 +0200	[thread overview]
Message-ID: <20231003173636.GZ13697@suse.cz> (raw)
In-Reply-To: <086c2106-2743-f1f7-dfc4-85a9403be47a@oracle.com>

On Tue, Oct 03, 2023 at 04:38:49PM +0800, Anand Jain wrote:
> On 3/10/23 16:00, Anand Jain wrote:
> > 
> > 
> > On 3/10/23 01:19, David Sterba wrote:
> >> On Fri, Sep 15, 2023 at 12:08:59PM +0800, Anand Jain wrote:
> >>> The misc-test/034-metadata_uuid test case, has four sets of disk 
> >>> images to
> >>> simulate failed writes during btrfstune -m|M operations. As of now, this
> >>> tests kernel only. Update the test case to verify btrfstune -m|M's
> >>> capacity to recover from the same scenarios.
> >>>
> >>> Signed-off-by: Anand Jain <anand.jain@oracle.com>
> >>
> >> With all the problems fixed, the test still fails.  I'm not sure which 
> >> case it
> >> is:
> >>
> >> ====== RUN CHECK root_helper losetup --find --show ./disk1.raw.restored
> >> /dev/loop0
> >> ====== RUN CHECK root_helper losetup --find --show ./disk2.raw.restored
> >> /dev/loop1
> >> ====== RUN CHECK root_helper udevadm settle
> >> ====== RUN CHECK root_helper /labs/dsterba/gits/btrfs-progs/btrfstune 
> >> -m /dev/loop1
> >> parent transid verify failed on 30425088 wanted 6 found 4
> >> parent transid verify failed on 30441472 wanted 6 found 4
> >> Error writing to device 1
> >> ERROR: failed to write tree block 30457856: Operation not permitted
> >> ERROR: btrfstune failed
> >> failed: root_helper /labs/dsterba/gits/btrfs-progs/btrfstune -m 
> >> /dev/loop1
> >> test failed for case 034-metadata-uuid
> >>
> >> Looks like a write that's beyond the device limit. I'll keep the patches
> >> and tests in devel so you can have a look.
> > 
> > 
> > As a root user, your devel branch passes here.
> > 
> > (Generally, I have been using the following command as root:)
> > 
> >   $ make TEST=034* test-misc
> >   [LD] fssum
> >   [LD] fsstress
> >   [TEST] misc-tests.sh
> >   [TEST/misc] 034-metadata-uuid
> >   Scanning /btrfs-progs/tests/misc-tests-results.txt
> > 
> > Let me try as a non-root user.
> > 
> > Also, could you please make sure that all the 
> > 'tests/misc-tests/034-metadata-uuid/*.restored' files are removed before 
> > starting the test case?
> 
> This pass as non-root.
> 
> $ sudo make TEST=034* test-misc
>      [LD]     fssum
>      [LD]     fsstress
>      [TEST]   misc-tests.sh
>      [TEST/misc]   034-metadata-uuid
> Scanning /btrfs-progs/tests/misc-tests-results.txt
> 
> So I think there might be some stale *restored images; Could you pls check.

It was indeed something on my side, the test now passes and also in CI.

  reply	other threads:[~2023-10-03 17:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-15  4:08 [PATCH 0/4 v4] btrfs-progs: recover from failed metadata_uuid port kernel Anand Jain
2023-09-15  4:08 ` [PATCH 1/4] btrfs-progs: tune use the latest bdev in fs_devices for super_copy Anand Jain
2023-09-15  4:08 ` [PATCH 2/4] btrfs-progs: add support to fix superblock with CHANGING_FSID_V2 flag Anand Jain
2023-09-15  4:08 ` [PATCH 3/4] btrfs-progs: recover from the failed btrfstune -m|M Anand Jain
2023-09-15  4:08 ` [PATCH 4/4] btrfs-progs: test btrfstune -m|M ability to fix previous failures Anand Jain
2023-10-02 17:16   ` David Sterba
2023-10-02 17:19   ` David Sterba
2023-10-03  8:00     ` Anand Jain
2023-10-03  8:38       ` Anand Jain
2023-10-03 17:36         ` David Sterba [this message]
2023-10-02 17:00 ` [PATCH 0/4 v4] btrfs-progs: recover from failed metadata_uuid port kernel David Sterba

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=20231003173636.GZ13697@suse.cz \
    --to=dsterba@suse.cz \
    --cc=anand.jain@oracle.com \
    --cc=dsterba@suse.com \
    --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.