1. 13 Dec, 2019 1 commit
  2. 29 Apr, 2019 3 commits
  3. 30 May, 2018 2 commits
  4. 12 Apr, 2018 1 commit
  5. 30 Mar, 2018 1 commit
  6. 19 Dec, 2016 1 commit
  7. 06 Dec, 2016 4 commits
  8. 26 Sep, 2016 1 commit
  9. 17 Sep, 2014 1 commit
    • Filipe Manana's avatar
      Btrfs: make btrfs_search_forward return with nodes unlocked · f98de9b9
      Filipe Manana authored
      None of the uses of btrfs_search_forward() need to have the path
      nodes (level >= 1) read locked, only the leaf needs to be locked
      while the caller processes it. Therefore make it return a path
      with all nodes unlocked, except for the leaf.
      This change is motivated by the observation that during a file
      fsync we repeatdly call btrfs_search_forward() and process the
      returned leaf while upper nodes of the returned path (level >= 1)
      are read locked, which unnecessarily blocks other tasks that want
      to write to the same fs/subvol btree.
      Therefore instead of modifying the fsync code to unlock all nodes
      with level >= 1 immediately after calling btrfs_search_forward(),
      change btrfs_search_forward() to do it, so that it benefits all
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
  10. 28 Jan, 2014 1 commit
  11. 12 Nov, 2013 1 commit
  12. 01 Sep, 2013 2 commits
    • Stefan Behrens's avatar
      Btrfs: check UUID tree during mount if required · 70f80175
      Stefan Behrens authored
      If the filesystem was mounted with an old kernel that was not
      aware of the UUID tree, this is detected by looking at the
      uuid_tree_generation field of the superblock (similar to how
      the free space cache is doing it). If a mismatch is detected
      at mount time, a thread is started that does two things:
      1. Iterate through the UUID tree, check each entry, delete those
         entries that are not valid anymore (i.e., the subvol does not
         exist anymore or the value changed).
      2. Iterate through the root tree, for each found subvolume, add
         the UUID tree entries for the subvolume (if they are not
         already there).
      This mechanism is also used to handle and repair errors that
      happened during the initial creation and filling of the tree.
      The update of the uuid_tree_generation field (which indicates
      that the state of the UUID tree is up to date) is blocked until
      all create and repair operations are successfully completed.
      Signed-off-by: default avatarStefan Behrens <sbehrens@giantdisaster.de>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: default avatarChris Mason <chris.mason@fusionio.com>
    • Stefan Behrens's avatar
      Btrfs: introduce a tree for items that map UUIDs to something · 07b30a49
      Stefan Behrens authored
      Mapping UUIDs to subvolume IDs is an operation with a high effort
      today. Today, the algorithm even has quadratic effort (based on the
      number of existing subvolumes), which means, that it takes minutes
      to send/receive a single subvolume if 10,000 subvolumes exist. But
      even linear effort would be too much since it is a waste. And these
      data structures to allow mapping UUIDs to subvolume IDs are created
      every time a btrfs send/receive instance is started.
      It is much more efficient to maintain a searchable persistent data
      structure in the filesystem, one that is updated whenever a
      subvolume/snapshot is created and deleted, and when the received
      subvolume UUID is set by the btrfs-receive tool.
      Therefore kernel code is added with this commit that is able to
      maintain data structures in the filesystem that allow to quickly
      search for a given UUID and to retrieve data that is assigned to
      this UUID, like which subvolume ID is related to this UUID.
      This commit adds a new tree to hold UUID-to-data mapping items. The
      key of the items is the full UUID plus the key type BTRFS_UUID_KEY.
      Multiple data blocks can be stored for a given UUID, a type/length/
      value scheme is used.
      Now follows the lengthy justification, why a new tree was added
      instead of using the existing root tree:
      The first approach was to not create another tree that holds UUID
      items. Instead, the items should just go into the top root tree.
      Unfortunately this confused the algorithm to assign the objectid
      of subvolumes and snapshots. The reason is that
      btrfs_find_free_objectid() calls btrfs_find_highest_objectid() for
      the first created subvol or snapshot after mounting a filesystem,
      and this function simply searches for the largest used objectid in
      the root tree keys to pick the next objectid to assign. Of course,
      the UUID keys have always been the ones with the highest offset
      value, and the next assigned subvol ID was wastefully huge.
      To use any other existing tree did not look proper. To apply a
      workaround such as setting the objectid to zero in the UUID item
      key and to implement collision handling would either add
      limitations (in case of a btrfs_extend_item() approach to handle
      the collisions) or a lot of complexity and source code (in case a
      key would be looked up that is free of collisions). Adding new code
      that introduces limitations is not good, and adding code that is
      complex and lengthy for no good reason is also not good. That's the
      justification why a completely new tree was introduced.
      Signed-off-by: default avatarStefan Behrens <sbehrens@giantdisaster.de>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: default avatarChris Mason <chris.mason@fusionio.com>