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/7] Rework reserve ticket handling
Date: Fri,  9 Aug 2019 09:33:20 -0400	[thread overview]
Message-ID: <20190809133327.26509-1-josef@toxicpanda.com> (raw)

While cleaning up some things around the global reserve and can_overcommit I
started getting ENOSPC's with plenty of space to make reservations.  The root
cause of the problem has to do with how we satisfy ticket reservations.

Previously we would add any space we were returning to the space info to the
first ticket we found.  The reason we did this was because new reservations just
check the counters to see if they can continue, so we didn't want them to get
reservations when we had waiters already queued up.  So instead of returning the
bytes to the space info, I'd add it to the ticket.  Then if we failed to satisfy
that ticket reservation we'd take any space we found and add it to the next guy
in case it satisfied the next ticket reservation.

This works generally well in practice, but there are several xfstests that run
ENOSPC tests against very small file systems.  These tests uncovered a corner
case when it comes to overcommitting.  If we overcommit the space, and then are
no longer allowed to overcommit, we won't actually give any returned space to
the tickets, because that would be really bad.  Instead we return that space to
the space_info and carry on.

What was biting us in these test cases was the fact that we had very small
metadata area, 8mib, and unlink asks for about 2mib of space.  If we had
overcommitted 8.1mib, we'd give back almost 2mib of space to the space_info,
which could have instead been used for the reservation.  This would result in an
early ENOSPC.

Since we are only doing this partial filling dance to avoid racing with new
reservations we just fix that race by checking if we have pending reservations
on the list, closing that race.  Then we are free to use the normal checks to
see if a ticket can be woken up.  This simplifies the code a bunch, we no longer
have to keep track of how much space the tickets were given and return those
bytes, and I could consolidate the wakeup code into one function instead of two.

The diffstat is as follows, this all passes xfstests, and sets us up nicely for
the upcoming changesets.

 fs/btrfs/block-group.c    |   5 +-
 fs/btrfs/block-rsv.c      |   5 --
 fs/btrfs/delalloc-space.c |   4 --
 fs/btrfs/extent-tree.c    |  13 +----
 fs/btrfs/space-info.c     | 140 +++++++++++-----------------------------------
 fs/btrfs/space-info.h     |  30 ++++++----
 6 files changed, 56 insertions(+), 141 deletions(-)

Thanks,

Josef


             reply	other threads:[~2019-08-09 13:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-09 13:33 Josef Bacik [this message]
2019-08-09 13:33 ` [PATCH 1/7] btrfs: do not allow reservations if we have pending tickets Josef Bacik
2019-08-09 13:33 ` [PATCH 2/7] btrfs: roll tracepoint into btrfs_space_info_update helper Josef Bacik
2019-08-09 13:33 ` [PATCH 3/7] btrfs: add space reservation tracepoint for reserved bytes Josef Bacik
2019-08-09 13:33 ` [PATCH 4/7] btrfs: rework btrfs_space_info_add_old_bytes Josef Bacik
2019-08-09 13:33 ` [PATCH 5/7] btrfs: refactor the ticket wakeup code Josef Bacik
2019-08-09 13:33 ` [PATCH 6/7] btrfs: rework wake_all_tickets Josef Bacik
2019-08-09 13:33 ` [PATCH 7/7] btrfs: remove orig_bytes from reserve_ticket 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=20190809133327.26509-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).