public inbox for linux-bcachefs@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Webb <chris@arachsys.com>
To: Kent Overstreet <kent.overstreet@gmail.com>
Cc: linux-bcachefs@vger.kernel.org
Subject: Re: Other (perhaps related) subvolume strangeness
Date: Mon, 11 Oct 2021 20:10:51 +0100	[thread overview]
Message-ID: <20211011191051.GA20049@arachsys.com> (raw)
In-Reply-To: <YWRbw6FOnHc54yrY@moria.home.lan>

Kent Overstreet <kent.overstreet@gmail.com> writes:

> Have you looked at ktest[1]? We've got some subvolume & snapshot tests in
> there, if you could add a few test cases for the things you're finding
> that'd be really helpful (and it's a really slick virtual machine testing
> environment, too)

Hi Kent. Ah I hadn't tried that, thanks! Looks like an excellent way to make
a more useful report with a test to reliably reproduce it. I've set it up
in a Debian chroot to make the dependencies easier to satisfy, and it's
working nicely.

> On Sun, Oct 10, 2021 at 07:55:50PM +0100, Chris Webb wrote:
>
> > After deleting a snapshot, creating a new one also uncovers a bug:
> 
> Wrote a test that reproduces it, I'll look further - thanks

This might be the same issue as test_subvol_snapshot_reuse_snapshot_name
from ktest/tests/bcachefs/subvol.ktest?

> > If instead I try to create a new snapshot with a different name:
> >   kernel BUG at fs/bcachefs/btree_key_cache.c:548!
> 
> This one I don't seem to be able to reproduce.

I failed to reproduce in ktest until I deleted and recreated a few extra
snapshots in a loop. I'll follow up putting this in a proper patch against
ktest with a changelog and so on, but

  test_subvol_snapshot_delete_repeat()
  {
      run_quiet "" bcachefs format -f --errors=panic /dev/sdb
      mount -t bcachefs /dev/sdb /mnt
      for i in $(seq 1 64); do
          bcachefs subvolume snapshot /mnt/$i
          bcachefs subvolume delete /mnt/$i
      done
      umount /mnt
  }

reliably reproduces for me using the head of your tree at the time of
writing, 33a19429e827:

  00015 ========= TEST   subvol_snapshot_delete_repeat
  00015 
  00015 bcachefs (sdb): recovering from clean shutdown, journal seq 4
  00015 bcachefs (sdb): going read-write
  00015 bcachefs (sdb): mounted with opts: errors=panic
  00017 ------------[ cut here ]------------
  00017 kernel BUG at fs/bcachefs/btree_key_cache.c:548!
  00017 KGDB: Waiting for remote debugger

It fails on attempt 12 for me.

> > bcachefs subvolume delete only works on snapshot subvolumes:
> 
> For the moment at least this is intended behaviour, since a regular
> subvolume can be removed with rm -rf. I've been meaning to check how btrfs
> does it, and match their behaviour wherever reasonable - do you know
> offhand what they do?

I don't know I'm afraid: it's been a few years since I tested out btrfs, and
I was mostly marvelling at the strange new magic of reflinks rather than
subvolumes and snapshots back then. :)

ENOENT (with strerror "No such file or directory") is quite a surprising
result for a user that isn't expecting it, especially as subvolume delete
'sounds' like the opposite of subvolume create.

I guess there's an argument that both snapshots and normal subvolumes can
be deleted by rm -r, and therefore subvolume delete is redundant anyway?

Best wishes,

Chris.

  reply	other threads:[~2021-10-11 19:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-10 13:44 rmdir() succeeds on an empty subvolume Chris Webb
2021-10-10 18:55 ` Other (perhaps related) subvolume strangeness Chris Webb
2021-10-11 15:44   ` Kent Overstreet
2021-10-11 19:10     ` Chris Webb [this message]
2021-10-11 21:07       ` [PATCH] [ktest] Test iterated snapshot create and delete with distinct names Chris Webb
2021-10-11 19:20 ` rmdir() succeeds on an empty subvolume Chris Webb

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=20211011191051.GA20049@arachsys.com \
    --to=chris@arachsys.com \
    --cc=kent.overstreet@gmail.com \
    --cc=linux-bcachefs@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