Re: [PATCH v3 0/9] Btrfs: free space B-tree

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4070 bytes --]

On 2015-09-14 02:04, Omar Sandoval wrote:
> Hi, everyone,
>
> I went back and fixed the issues that came up since v2. Changes below. I
> removed Josef's Reviewed-by on patch 9 because it was completely
> rewritten to change the mount options like Dave suggested. These are
> still based on 4.2
>
> Thanks!
>
> Changes from v2->v3:
>
> - Fixed a warning in the free space tree sanity tests caught by Zhao Lei.
> - Moved the addition of a block group to the free space tree to occur either on
>    the first attempt to modify the free space for the block group or in
>    btrfs_create_pending_block_groups(), whichever happens first. This avoids a
>    deadlock (lock recursion) when modifying the free space tree requires
>    allocating a new block group. In order to do this, it was simpler to change
>    the on-disk semantics: the superblock stripes will now appear to be free space
>    according to the free space tree, but load_free_space_tree() will still
>    exclude them when building the in-memory free space cache.
> - Changed the free_space_tree option to space_cache=v2 and made clear_cache
>    clear the free space tree. If the free space tree has been created,
>    the mount will fail unless space_cache=v2 or nospace_cache,clear_cache
>    is given because we cannot allow the free space tree to get out of
>    date.
> - Did a once-over of the code and caught a couple of error handling typos.
>
> v2: http://www.spinics.net/lists/linux-btrfs/msg46796.html
>
> Changes from v1->v2:
>
> - Cleaned up a bunch of unnecessary instances of "if (ret) goto out; ret = 0"
> - Added aborts in the free space tree code closer to the site the error is
>    encountered: where we add or remove block groups, add or remove free space,
>    and also when we convert formats
> - Moved loading of the free space tree into caching_thread() and added a new
>    patch 3 in preparation for it
> - Commented a bunch of stuff in the extent buffer bitmap operations and
>    refactored some of the complicated logic
>
> v1: http://www.spinics.net/lists/linux-btrfs/msg46713.html
>
> Omar Sandoval (9):
>    Btrfs: add extent buffer bitmap operations
>    Btrfs: add extent buffer bitmap sanity tests
>    Btrfs: add helpers for read-only compat bits
>    Btrfs: refactor caching_thread()
>    Btrfs: introduce the free space B-tree on-disk format
>    Btrfs: implement the free space B-tree
>    Btrfs: add free space tree sanity tests
>    Btrfs: wire up the free space tree to the extent tree
>    Btrfs: add free space tree mount option
>
>   fs/btrfs/Makefile                      |    5 +-
>   fs/btrfs/ctree.h                       |  157 +++-
>   fs/btrfs/disk-io.c                     |   38 +
>   fs/btrfs/extent-tree.c                 |   98 +-
>   fs/btrfs/extent_io.c                   |  183 +++-
>   fs/btrfs/extent_io.h                   |   10 +-
>   fs/btrfs/free-space-tree.c             | 1581 ++++++++++++++++++++++++++++++++
>   fs/btrfs/free-space-tree.h             |   72 ++
>   fs/btrfs/super.c                       |   56 +-
>   fs/btrfs/tests/btrfs-tests.c           |   52 ++
>   fs/btrfs/tests/btrfs-tests.h           |   10 +
>   fs/btrfs/tests/extent-io-tests.c       |  138 ++-
>   fs/btrfs/tests/free-space-tests.c      |   35 +-
>   fs/btrfs/tests/free-space-tree-tests.c |  571 ++++++++++++
>   fs/btrfs/tests/qgroup-tests.c          |   20 +-
>   include/trace/events/btrfs.h           |    3 +-
>   16 files changed, 2922 insertions(+), 107 deletions(-)
>   create mode 100644 fs/btrfs/free-space-tree.c
>   create mode 100644 fs/btrfs/free-space-tree.h
>   create mode 100644 fs/btrfs/tests/free-space-tree-tests.c
>
I've tested this in a couple of different VM's and got noticeable 
performance improvements in both general usage and mount times.  I also 
threw everything I can think of at it (short of attempting to craft 
filesystem images specifically to break it), and nothing broke, so:

Tested-by: Austin S. Hemmelgarn <ahferroin7@gmail.com>


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]