1. 01 Nov, 2017 8 commits
    • Josef Bacik's avatar
      Btrfs: rework outstanding_extents · 8b62f87b
      Josef Bacik authored
      Right now we do a lot of weird hoops around outstanding_extents in order
      to keep the extent count consistent.  This is because we logically
      transfer the outstanding_extent count from the initial reservation
      through the set_delalloc_bits.  This makes it pretty difficult to get a
      handle on how and when we need to mess with outstanding_extents.
      
      Fix this by revamping the rules of how we deal with outstanding_extents.
      Now instead everybody that is holding on to a delalloc extent is
      required to increase the outstanding extents count for itself.  This
      means we'll have something like this
      
      btrfs_delalloc_reserve_metadata	- outstanding_extents = 1
       btrfs_set_extent_delalloc	- outstanding_extents = 2
      btrfs_release_delalloc_extents	- outstanding_extents = 1
      
      for an initial file write.  Now take the append write where we extend an
      existing delalloc range but still under the maximum extent size
      
      btrfs_delalloc_reserve_metadata - outstanding_extents = 2
        btrfs_set_extent_delalloc
          btrfs_set_bit_hook		- outstanding_extents = 3
          btrfs_merge_extent_hook	- outstanding_extents = 2
      btrfs_delalloc_release_extents	- outstanding_extnets = 1
      
      In order to make the ordered extent transition we of course must now
      make ordered extents carry their own outstanding_extent reservation, so
      for cow_file_range we end up with
      
      btrfs_add_ordered_extent	- outstanding_extents = 2
      clear_extent_bit		- outstanding_extents = 1
      btrfs_remove_ordered_extent	- outstanding_extents = 0
      
      This makes all manipulations of outstanding_extents much more explicit.
      Every successful call to btrfs_delalloc_reserve_metadata _must_ now be
      combined with btrfs_release_delalloc_extents, even in the error case, as
      that is the only function that actually modifies the
      outstanding_extents counter.
      
      The drawback to this is now we are much more likely to have transient
      cases where outstanding_extents is much larger than it actually should
      be.  This could happen before as we manipulated the delalloc bits, but
      now it happens basically at every write.  This may put more pressure on
      the ENOSPC flushing code, but I think making this code simpler is worth
      the cost.  I have another change coming to mitigate this side-effect
      somewhat.
      
      I also added trace points for the counter manipulation.  These were used
      by a bpf script I wrote to help track down leak issues.
      Signed-off-by: default avatarJosef Bacik <jbacik@fb.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      8b62f87b
    • Zygo Blaxell's avatar
      btrfs: increase output size for LOGICAL_INO_V2 ioctl · b115e3bc
      Zygo Blaxell authored
      Build-server workloads have hundreds of references per file after dedup.
      Multiply by a few snapshots and we quickly exhaust the limit of 2730
      references per extent that can fit into a 64K buffer.
      
      Raise the limit to 16M to be consistent with other btrfs ioctls
      (e.g. TREE_SEARCH_V2, FILE_EXTENT_SAME).
      
      To minimize surprising userspace behavior, apply this change only to
      the LOGICAL_INO_V2 ioctl.
      Signed-off-by: default avatarZygo Blaxell <ce3g8jdj@umail.furryterror.org>
      Reviewed-by: default avatarHans van Kranenburg <hans.van.kranenburg@mendix.com>
      Tested-by: default avatarHans van Kranenburg <hans.van.kranenburg@mendix.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      b115e3bc
    • Zygo Blaxell's avatar
      btrfs: add a flags argument to LOGICAL_INO and call it LOGICAL_INO_V2 · d24a67b2
      Zygo Blaxell authored
      Now that check_extent_in_eb()'s extent offset filter can be turned off,
      we need a way to do it from userspace.
      
      Add a 'flags' field to the btrfs_logical_ino_args structure to disable
      extent offset filtering, taking the place of one of the existing
      reserved[] fields.
      
      Previous versions of LOGICAL_INO neglected to check whether any of the
      reserved fields have non-zero values.  Assigning meaning to those fields
      now may change the behavior of existing programs that left these fields
      uninitialized.  The lack of a zero check also means that new programs
      have no way to know whether the kernel is honoring the flags field.
      
      To avoid these problems, define a new ioctl LOGICAL_INO_V2.  We can
      use the same argument layout as LOGICAL_INO, but shorten the reserved[]
      array by one element and turn it into the 'flags' field.  The V2 ioctl
      explicitly checks that reserved fields and unsupported flag bits are zero
      so that userspace can negotiate future feature bits as they are defined.
      
      Since the memory layouts of the two ioctls' arguments are compatible,
      there is no need for a separate function for logical_to_ino_v2 (contrast
      with tree_search_v2 vs tree_search where the layout and code are quite
      different).  A version parameter and an 'if' statement will suffice.
      
      Now that we have a flags field in logical_ino_args, add a flag
      BTRFS_LOGICAL_INO_ARGS_IGNORE_OFFSET to get the behavior we want,
      and pass it down the stack to iterate_inodes_from_logical.
      
      Motivation and background, copied from the patchset cover letter:
      
      Suppose we have a file with one extent:
      
          root@tester:~# zcat /usr/share/doc/cpio/changelog.gz > /test/a
          root@tester:~# sync
      
      Split the extent by overwriting it in the middle:
      
          root@tester:~# cat /dev/urandom | dd bs=4k seek=2 skip=2 count=1 conv=notrunc of=/test/a
      
      We should now have 3 extent refs to 2 extents, with one block unreachable.
      The extent tree looks like:
      
          root@tester:~# btrfs-debug-tree /dev/vdc -t 2
          [...]
                  item 9 key (1103101952 EXTENT_ITEM 73728) itemoff 15942 itemsize 53
                          extent refs 2 gen 29 flags DATA
                          extent data backref root 5 objectid 261 offset 0 count 2
          [...]
                  item 11 key (1103175680 EXTENT_ITEM 4096) itemoff 15865 itemsize 53
                          extent refs 1 gen 30 flags DATA
                          extent data backref root 5 objectid 261 offset 8192 count 1
          [...]
      
      and the ref tree looks like:
      
          root@tester:~# btrfs-debug-tree /dev/vdc -t 5
          [...]
                  item 6 key (261 EXTENT_DATA 0) itemoff 15825 itemsize 53
                          extent data disk byte 1103101952 nr 73728
                          extent data offset 0 nr 8192 ram 73728
                          extent compression(none)
                  item 7 key (261 EXTENT_DATA 8192) itemoff 15772 itemsize 53
                          extent data disk byte 1103175680 nr 4096
                          extent data offset 0 nr 4096 ram 4096
                          extent compression(none)
                  item 8 key (261 EXTENT_DATA 12288) itemoff 15719 itemsize 53
                          extent data disk byte 1103101952 nr 73728
                          extent data offset 12288 nr 61440 ram 73728
                          extent compression(none)
          [...]
      
      There are two references to the same extent with different, non-overlapping
      byte offsets:
      
          [------------------72K extent at 1103101952----------------------]
          [--8K----------------|--4K unreachable----|--60K-----------------]
          ^                                         ^
          |                                         |
          [--8K ref offset 0--][--4K ref offset 0--][--60K ref offset 12K--]
                               |
                               v
                               [-----4K extent-----] at 1103175680
      
      We want to find all of the references to extent bytenr 1103101952.
      
      Without the patch (and without running btrfs-debug-tree), we have to
      do it with 18 LOGICAL_INO calls:
      
          root@tester:~# btrfs ins log 1103101952 -P /test/
          Using LOGICAL_INO
          inode 261 offset 0 root 5
      
          root@tester:~# for x in $(seq 0 17); do btrfs ins log $((1103101952 + x * 4096)) -P /test/; done 2>&1 | grep inode
          inode 261 offset 0 root 5
          inode 261 offset 4096 root 5   <- same extent ref as offset 0
                                         (offset 8192 returns empty set, not reachable)
          inode 261 offset 12288 root 5
          inode 261 offset 16384 root 5  \
          inode 261 offset 20480 root 5  |
          inode 261 offset 24576 root 5  |
          inode 261 offset 28672 root 5  |
          inode 261 offset 32768 root 5  |
          inode 261 offset 36864 root 5  \
          inode 261 offset 40960 root 5   > all the same extent ref as offset 12288.
          inode 261 offset 45056 root 5  /  More processing required in userspace
          inode 261 offset 49152 root 5  |  to figure out these are all duplicates.
          inode 261 offset 53248 root 5  |
          inode 261 offset 57344 root 5  |
          inode 261 offset 61440 root 5  |
          inode 261 offset 65536 root 5  |
          inode 261 offset 69632 root 5  /
      
      In the worst case the extents are 128MB long, and we have to do 32768
      iterations of the loop to find one 4K extent ref.
      
      With the patch, we just use one call to map all refs to the extent at once:
          root@tester:~# btrfs ins log 1103101952 -P /test/
          Using LOGICAL_INO_V2
          inode 261 offset 0 root 5
          inode 261 offset 12288 root 5
      
      The TREE_SEARCH ioctl allows userspace to retrieve the offset and
      extent bytenr fields easily once the root, inode and offset are known.
      This is sufficient information to build a complete map of the extent
      and all of its references.  Userspace can use this information to make
      better choices to dedup or defrag.
      Signed-off-by: default avatarZygo Blaxell <ce3g8jdj@umail.furryterror.org>
      Reviewed-by: default avatarHans van Kranenburg <hans.van.kranenburg@mendix.com>
      Tested-by: default avatarHans van Kranenburg <hans.van.kranenburg@mendix.com>
      [ copy background and motivation from cover letter ]
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      d24a67b2
    • Zygo Blaxell's avatar
      btrfs: add a flag to iterate_inodes_from_logical to find all extent refs for uncompressed extents · c995ab3c
      Zygo Blaxell authored
      The LOGICAL_INO ioctl provides a backward mapping from extent bytenr and
      offset (encoded as a single logical address) to a list of extent refs.
      LOGICAL_INO complements TREE_SEARCH, which provides the forward mapping
      (extent ref -> extent bytenr and offset, or logical address).  These are
      useful capabilities for programs that manipulate extents and extent
      references from userspace (e.g. dedup and defrag utilities).
      
      When the extents are uncompressed (and not encrypted and not other),
      check_extent_in_eb performs filtering of the extent refs to remove any
      extent refs which do not contain the same extent offset as the 'logical'
      parameter's extent offset.  This prevents LOGICAL_INO from returning
      references to more than a single block.
      
      To find the set of extent references to an uncompressed extent from [a, b),
      userspace has to run a loop like this pseudocode:
      
      	for (i = a; i < b; ++i)
      		extent_ref_set += LOGICAL_INO(i);
      
      At each iteration of the loop (up to 32768 iterations for a 128M extent),
      data we are interested in is collected in the kernel, then deleted by
      the filter in check_extent_in_eb.
      
      When the extents are compressed (or encrypted or other), the 'logical'
      parameter must be an extent bytenr (the 'a' parameter in the loop).
      No filtering by extent offset is done (or possible?) so the result is
      the complete set of extent refs for the entire extent.  This removes
      the need for the loop, since we get all the extent refs in one call.
      
      Add an 'ignore_offset' argument to iterate_inodes_from_logical,
      [...several levels of function call graph...], and check_extent_in_eb, so
      that we can disable the extent offset filtering for uncompressed extents.
      This flag can be set by an improved version of the LOGICAL_INO ioctl to
      get either behavior as desired.
      
      There is no functional change in this patch.  The new flag is always
      false.
      Signed-off-by: default avatarZygo Blaxell <ce3g8jdj@umail.furryterror.org>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      [ minor coding style fixes ]
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      c995ab3c
    • Nikolay Borisov's avatar
      btrfs: send: remove unused code · eb7b9d6a
      Nikolay Borisov authored
      This code was first introduced in 31db9f7c ("Btrfs: introduce
      BTRFS_IOC_SEND for btrfs send/receive") and it was not functional, then
      it got slightly refactored in e938c8ad ("Btrfs: code cleanups for
      send/receive"), alas it was still dead. So let's remove it for good!
      Signed-off-by: default avatarNikolay Borisov <nborisov@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      eb7b9d6a
    • Anand Jain's avatar
      btrfs: remove BUG_ON in btrfs_rm_dev_replace_free_srcdev() · 6dd38f81
      Anand Jain authored
      That was only an extra check to tackle a few bugs around this area, now
      its safe to remove it.  Replace it by an ASSERT.
      Signed-off-by: default avatarAnand Jain <anand.jain@oracle.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      6dd38f81
    • Adam Borowski's avatar
      btrfs: allow setting zlib compression level via :9 · fa4d885a
      Adam Borowski authored
      This is bikeshedding, but it seems people are drastically more likely to
      understand "zlib:9" as compression level rather than an algorithm
      version compared to "zlib9".
      
      Based on feedback on the mailinglist, the ":9" will be the only accepted
      syntax. The level must be a single digit. Unrecognized format will
      result to the default, for forward compatibility in a similar way the
      compression algorithm specifier was relaxed in commit
      a7164fa4 ("btrfs: prepare for extensions in compression
      options").
      Signed-off-by: default avatarAdam Borowski <kilobyte@angband.pl>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      [ tighten the accepted format ]
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      fa4d885a
    • David Sterba's avatar
      btrfs: allow to set compression level for zlib · f51d2b59
      David Sterba authored
      Preliminary support for setting compression level for zlib, the
      following works:
      
      $ mount -o compess=zlib                 # default
      $ mount -o compess=zlib0                # same
      $ mount -o compess=zlib9                # level 9, slower sync, less data
      $ mount -o compess=zlib1                # level 1, faster sync, more data
      $ mount -o remount,compress=zlib3	# level set by remount
      
      The compress-force works the same as compress'.  The level is visible in
      the same format in /proc/mounts. Level set via file property does not
      work yet.
      
      Required patch: "btrfs: prepare for extensions in compression options"
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      f51d2b59
  2. 30 Oct, 2017 32 commits