linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH 0/8][v2] Cleanup how we handle root refs, part 2
Date: Fri, 17 Jan 2020 08:52:30 -0500	[thread overview]
Message-ID: <20200117135238.41601-1-josef@toxicpanda.com> (raw)

v1->v2:
- Rebased onto latest misc-next.
- Fixed a problem where we were dropping the ino_cache_inode in the final put of
  the root, which is braindead since it was holding a ref on that root.

--------------- Original email -------------------
This series depends on part 1 and is the final bit of cleaning up how we handle
root refs.  Historically the ref counting has been just about kfree'ing the root
itself and not actually cleaning up the root and free'ing it.  This makes it
sort of awkward to handle the lifetime of a root, as we will just free a bunch
of things related to the root, but then not free the actual root until we drop
the last reference.

This patch series brings the actual cleanup of the root inside the ref
accounting for the root.  In addition to that we also now hold refs on the root
for all of the various users of the root in order to make the lifetime more
coherent.  Previously if you looked up a root we just held it in memory until
unmount and then we had to do two put's to clear it out.  Now we hold refs to
the root when we open an inode in the root, so we could get rid of this extra
ref holding.  Now we hold refs for discrete operations, like putting it in the
radix tree, adding to the dead roots list, and of course opening an inode.

This final piece allows us to remove the subvol_srcu, which was the reason for
all of this work.  I fixed the original deadlock, but it's use was sporadic and
inconsistent, which is a recipe for trouble.

Unfortunately I was not able to kill the per-root inode rb tree yet.  We use it
in relocation to drop the extent cache for extents we are relocating, and
there's not a very clear way to accomplish that without the inode rbtree right
now.  However this work means that once I've fixed that problem we can delete
the inode rbtree completely.  Thanks,

Josef



             reply	other threads:[~2020-01-17 13:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-17 13:52 Josef Bacik [this message]
2020-01-17 13:52 ` [PATCH 1/8] btrfs: make the extent buffer leak check per fs info Josef Bacik
2020-01-17 13:52 ` [PATCH 2/8] btrfs: move ino_cache_inode dropping Josef Bacik
2020-01-17 13:52 ` [PATCH 3/8] btrfs: move the root freeing stuff into btrfs_put_root Josef Bacik
2020-01-17 13:52 ` [PATCH 4/8] btrfs: make inodes hold a ref on their roots Josef Bacik
2020-01-17 13:52 ` [PATCH 5/8] btrfs: hold a ref on the root on the dead roots list Josef Bacik
2020-01-17 13:52 ` [PATCH 6/8] btrfs: don't take an extra root ref at allocation time Josef Bacik
2020-01-17 13:52 ` [PATCH 7/8] btrfs: make btrfs_cleanup_fs_roots use the fs_roots_radix_lock Josef Bacik
2020-01-17 13:52 ` [PATCH 8/8] btrfs: kill the subvol_srcu Josef Bacik

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=20200117135238.41601-1-josef@toxicpanda.com \
    --to=josef@toxicpanda.com \
    --cc=kernel-team@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).