From: Chris Webb <chris@arachsys.com>
To: linux-bcachefs@vger.kernel.org
Cc: Kent Overstreet <kent.overstreet@gmail.com>
Subject: Other (perhaps related) subvolume strangeness
Date: Sun, 10 Oct 2021 19:55:50 +0100 [thread overview]
Message-ID: <20211010185549.GA24560@arachsys.com> (raw)
In-Reply-To: <20211010134413.GA31142@arachsys.com>
A couple of (perhaps related) issues I noticed...
bcachefs subvolume delete only works on snapshot subvolumes:
# bcachefs subvolume create /mnt/s
# bcachefs subvolume snapshot /mnt/s /mnt/t
# bcachefs subvolume delete /mnt/s
BCH_IOCTL_SUBVOLUME_DESTROY ioctl error: No such file or directory
# bcachefs subvolume delete /mnt/t
#
Following through, bch2_ioctl_subvolume_destroy() calls __bch2_unlink() and
thus bch2_subvolume_delete() with deleting_snapshot == 1, so
0 <= deleting_snapshot != BCH_SUBVOLUME_SNAP(subvol.v)
and it therefore returns -ENOENT. (Just calling __bch2_unlink() with -1
instead of 1 isn't a sufficient fix on its own, though, as this will fail to
delete non-empty snapshot subvolumes.)
After deleting a snapshot, creating a new one also uncovers a bug:
# bcachefs subvolume snapshot /mnt/s
# bcachefs subvolume delete /mnt/s
# ls /mnt
lost+found
# bcachefs subvolume snapshot /mnt/s
BCH_IOCTL_SUBVOLUME_CREATE ioctl error: File exists
If instead I try to create a new snapshot with a different name:
# bcachefs subvolume snapshot /mnt/
[hangs]
^C
# dmesg -t
bcachefs (zram1): recovering from clean shutdown, journal seq 4
bcachefs (zram1): going read-write
bcachefs (zram1): mounted with opts: (null)
------------[ cut here ]------------
kernel BUG at fs/bcachefs/btree_key_cache.c:548!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 6 PID: 1397 Comm: bcachefs Tainted: G W 5.13.0+ #5
Hardware name: To Be Filled By O.E.M. 4X4 BOX/4X4-4000 Series, BIOS P1.30 11/27/2020
RIP: 0010:bch2_btree_key_cache_verify_clean+0x33/0x40
Code: 8b 45 10 48 89 04 24 48 8b 45 18 48 89 44 24 08 8b 45 20 89 44 24 10 48 8b 3f e8 08 e6 ff ff 48 83 c4 18 48 85 c0 75 02 c9 c3 <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 57 49 89 ff
RSP: 0018:ffffa5680307ba28 EFLAGS: 00010286
RAX: ffff9b84459d92c0 RBX: ffffa5680307bc38 RCX: ffffffffffffff80
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff9b844108d580
RBP: ffffa5680307ba28 R08: ffff9b8445946049 R09: 0000000000000000
R10: 0000000000000002 R11: 0000000000000000 R12: ffff9b844ef20000
R13: ffffffff8ea60340 R14: ffff9b844fb24a40 R15: ffff9b844ef20000
FS: 00007f0776dd4380(0000) GS:ffff9b8b2f780000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055efddee1a60 CR3: 000000010d38a000 CR4: 0000000000350ee0
Call Trace:
__bch2_trans_commit+0xea/0x710
__bch2_create+0x30e/0x640
? generic_permission+0x25/0x200
? __bch2_create+0x148/0x640
bch2_fs_file_ioctl+0x718/0x8a0
? bch2_fs_file_ioctl+0x718/0x8a0
__x64_sys_ioctl+0x3e3/0x930
? __x64_sys_ioctl+0x3e3/0x930
? do_sys_openat2+0x82/0x150
do_syscall_64+0x40/0x80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f0776fb46fd
Code: 03 44 24 10 83 c1 08 89 0c 24 eb 0e 48 8b 44 24 08 48 8d 48 08 48 89 4c 24 08 48 8b 10 48 63 ff 48 63 f6 b8 10 00 00 00 0f 05 <9b> 48 63 f8 e8 ba 73 fe ff 48 81 c4 d8 00 00 00 c3 0f be 05 b5 1b
RSP: 002b:00007fff375a84f0 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007fff375a9e16 RCX: 00007f0776fb46fd
RDX: 00007fff375a85f0 RSI: 000000004020bc10 RDI: 0000000000000003
RBP: 0000000000000000 R08: 00007f0776f89500 R09: 0000000000000000
R10: 00007fff375a8510 R11: 0000000000000206 R12: 000055efddfdbc50
R13: 0000000000000001 R14: 0000000000000000 R15: 000055efdde79012
Modules linked in:
---[ end trace 2ef23b87f042ceae ]---
RIP: 0010:bch2_btree_key_cache_verify_clean+0x33/0x40
Code: 8b 45 10 48 89 04 24 48 8b 45 18 48 89 44 24 08 8b 45 20 89 44 24 10 48 8b 3f e8 08 e6 ff ff 48 83 c4 18 48 85 c0 75 02 c9 c3 <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 57 49 89 ff
RSP: 0018:ffffa5680307ba28 EFLAGS: 00010286
RAX: ffff9b84459d92c0 RBX: ffffa5680307bc38 RCX: ffffffffffffff80
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff9b844108d580
RBP: ffffa5680307ba28 R08: ffff9b8445946049 R09: 0000000000000000
R10: 0000000000000002 R11: 0000000000000000 R12: ffff9b844ef20000
R13: ffffffff8ea60340 R14: ffff9b844fb24a40 R15: ffff9b844ef20000
FS: 00007f0776dd4380(0000) GS:ffff9b8b2f780000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055efddee1a60 CR3: 000000010d38a000 CR4: 0000000000350ee0
Best wishes,
Chris.
next prev parent reply other threads:[~2021-10-10 18:55 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 ` Chris Webb [this message]
2021-10-11 15:44 ` Other (perhaps related) subvolume strangeness Kent Overstreet
2021-10-11 19:10 ` Chris Webb
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=20211010185549.GA24560@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.