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.
next prev parent 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 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.