• Filipe Manana's avatar
    btrfs: make checksum item extension more efficient · cc14600c
    Filipe Manana authored
    When we want to add checksums into the checksums tree, or a log tree, we
    try whenever possible to extend existing checksum items, as this helps
    reduce amount of metadata space used, since adding a new item uses extra
    metadata space for a btrfs_item structure (25 bytes).
    
    However we have two inefficiencies in the current approach:
    
    1) After finding a checksum item that covers a range with an end offset
       that matches the start offset of the checksum range we want to insert,
       we release the search path populated by btrfs_lookup_csum() and then
       do another COW search on tree with the goal of getting additional
       space for at least one checksum. Doing this path release and then
       searching again is a waste of time because very often the leaf already
       has enough free space for at least one more checksum;
    
    2) After the COW search that guarantees we get free space in the leaf for
       at least one more checksum, we end up not doing the extension of the
       previous checksum item, and fallback to insertion of a new checksum
       item, if the leaf doesn't have an amount of free space larger then the
       space required for 2 checksums plus one btrfs_item structure - this is
       pointless for two reasons:
    
       a) We want to extend an existing item, so we don't need to account for
          a btrfs_item structure (25 bytes);
    
       b) We made the COW search with an insertion size for 1 single checksum,
          so if the leaf ends up with a free space amount smaller then 2
          checksums plus the size of a btrfs_item structure, we give up on the
          extension of the existing item and jump to the 'insert' label, where
          we end up releasing the path and then doing yet another search to
          insert a new checksum item for a single checksum.
    
    Fix these inefficiencies by doing the following:
    
    - For case 1), before releasing the path just check if the leaf already
      has enough space for at least 1 more checksum, and if it does, jump
      directly to the item extension code, with releasing our current path,
      which was already COWed by btrfs_lookup_csum();
    
    - For case 2), fix the logic so that for item extension we require only
      that the leaf has enough free space for 1 checksum, and not a minimum
      of 2 checksums plus space for a btrfs_item structure.
    Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
    Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
    cc14600c
file-item.c 31.2 KB