From: Alexandre Oliva <oliva@lsd.ic.unicamp.br>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 00/20] Here's my current btrfs patchset
Date: Mon, 28 Nov 2011 17:17:05 -0200 [thread overview]
Message-ID: <cover.1322507825.git.oliva@lsd.ic.unicamp.br> (raw)
The first 11 patches are relatively simple fixes or improvements that
I suppose go could make it even in 3.2 (02 is particularly essential
to avoid progressive performance degradation and metadata space waste
in the default clustered allocation strategy).
Patch 12 and its complement 15, and also 19, are debugging aids that
helped me track down the problem fixed in 02.
Patch 13 is a revised version of the larger-clusters patch I posted
before, that adds a microoptimization to the bitmap computations to
the earlier version.
Patches 14 to 20 are probably not suitable for inclusion, and are
provided only for reference, although I'm still undecided on 16: it
seems to me to make sense to stick to the ordered list and index
instead of jumping to the current cluster's block group, but it may
also make sense performance-wise to start at the current cluster and
advance from there. We still do that, as long as we find a cluster
to begin with, but I'm yet to double check on the race that causes
multiple subsequent releases/creation of clusters under heavy load.
I'm sure I saw it, and I no longer do, but now I'm no longer sure
whether this is the patch that fixed it, or about the details of how
we came about that scenario.
Patches 14, 17, 18 and 20 were posted before, and I'm probably dropping
them from future patchsets unless I find them to be still useful.
Alexandre Oliva (20):
Btrfs: enable removal of second disk with raid1 metadata
Btrfs: initialize new bitmaps' list
Btrfs: fix comment typo
Btrfs: reset cluster's max_size when creating bitmap cluster
Btrfs: start search for new cluster at the beginning of the block
group
Btrfs: skip block groups without enough space for a cluster
Btrfs: don't set up allocation result twice
Btrfs: try to allocate from cluster even at LOOP_NO_EMPTY_SIZE
Btrfs: skip allocation attempt from empty cluster
Btrfs: report reason for failed relocation
Btrfs: note when a bitmap is skipped because its list is in use
Btrfs: introduce verbose debug mode for patched clustered allocation
recovery
Btrfs: revamp clustered allocation logic
Btrfs: introduce option to rebalance only metadata
Btrfs: activate allocation debugging
Btrfs: try cluster but don't advance in search list
Btrfs: introduce -o cluster and -o nocluster
Btrfs: add -o mincluster option
Btrfs: log when a bitmap is rejected for a cluster
Btrfs: don't waste metadata block groups for clustered allocation
fs/btrfs/ctree.h | 3 +-
fs/btrfs/extent-tree.c | 297 ++++++++++++++++++++++++++++++++-----------
fs/btrfs/free-space-cache.c | 132 ++++++++++---------
fs/btrfs/ioctl.c | 2 +
fs/btrfs/ioctl.h | 3 +
fs/btrfs/relocation.c | 8 +
fs/btrfs/super.c | 31 ++++-
fs/btrfs/volumes.c | 39 +++++-
fs/btrfs/volumes.h | 1 +
9 files changed, 369 insertions(+), 147 deletions(-)
--
1.7.4.4
next reply other threads:[~2011-11-28 19:33 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-28 19:17 Alexandre Oliva [this message]
2011-10-14 15:10 ` [PATCH 13/20] Btrfs: revamp clustered allocation logic Alexandre Oliva
2011-10-29 4:20 ` [PATCH 17/20] Btrfs: introduce -o cluster and -o nocluster Alexandre Oliva
2011-11-08 14:25 ` [PATCH 14/20] Btrfs: introduce option to rebalance only metadata Alexandre Oliva
2011-11-08 14:33 ` [PATCH 01/20] Btrfs: enable removal of second disk with raid1 metadata Alexandre Oliva
2011-11-10 22:55 ` [PATCH 18/20] Btrfs: add -o mincluster option Alexandre Oliva
2011-11-16 3:25 ` [PATCH 10/20] Btrfs: report reason for failed relocation Alexandre Oliva
2011-11-25 23:47 ` [PATCH 20/20] Btrfs: don't waste metadata block groups for clustered allocation Alexandre Oliva
2011-11-26 21:19 ` [PATCH 12/20] Btrfs: introduce verbose debug mode for patched clustered allocation recovery Alexandre Oliva
2011-11-26 23:53 ` [PATCH 05/20] Btrfs: start search for new cluster at the beginning of the block group Alexandre Oliva
2011-11-27 2:05 ` [PATCH 09/20] Btrfs: skip allocation attempt from empty cluster Alexandre Oliva
2011-11-27 22:49 ` [PATCH 16/20] Btrfs: try cluster but don't advance in search list Alexandre Oliva
2011-11-28 0:07 ` [PATCH 08/20] Btrfs: try to allocate from cluster even at LOOP_NO_EMPTY_SIZE Alexandre Oliva
2011-11-28 2:04 ` [PATCH 15/20] Btrfs: activate allocation debugging Alexandre Oliva
2011-11-28 13:52 ` [PATCH 02/20] Btrfs: initialize new bitmaps' list Alexandre Oliva
2011-11-29 21:00 ` Christian Brunner
2011-11-30 23:28 ` Alexandre Oliva
2011-12-01 14:50 ` Christian Brunner
2011-12-07 20:50 ` Christian Brunner
2011-12-09 15:17 ` Christian Brunner
2011-12-12 7:47 ` Alexandre Oliva
2011-12-12 8:05 ` Christian Brunner
2011-11-28 14:07 ` [PATCH 04/20] Btrfs: reset cluster's max_size when creating bitmap cluster Alexandre Oliva
2011-11-28 14:22 ` [PATCH 11/20] Btrfs: note when a bitmap is skipped because its list is in use Alexandre Oliva
2011-11-28 14:23 ` [PATCH 19/20] Btrfs: log when a bitmap is rejected for a cluster Alexandre Oliva
2011-11-28 14:30 ` [PATCH 06/20] Btrfs: skip block groups without enough space " Alexandre Oliva
2011-11-28 14:36 ` [PATCH 07/20] Btrfs: don't set up allocation result twice Alexandre Oliva
2011-11-28 15:41 ` [PATCH 03/20] Btrfs: fix comment typo Alexandre Oliva
2011-11-29 2:25 ` [PATCH 00/20] Here's my current btrfs patchset Li Zefan
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=cover.1322507825.git.oliva@lsd.ic.unicamp.br \
--to=oliva@lsd.ic.unicamp.br \
--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).