Btrfs: change delayed reservation fallback behavior
authorJosef Bacik <jbacik@fb.com>
Fri, 25 Mar 2016 17:25:50 +0000 (13:25 -0400)
committerDavid Sterba <dsterba@suse.com>
Thu, 7 Jul 2016 16:45:53 +0000 (18:45 +0200)
commitc48f49d63dfea12c0173fb2e99db1308f39c23ae
tree928ece07ce25e6c771f97de68fe2f7bdd091716a
parent48c3d480e4f746edb0bd3b84b4bd987ef8728560
Btrfs: change delayed reservation fallback behavior

We reserve space for the inode update when we first reserve space for writing to
a file.  However there are lots of ways that we can use this reservation and not
have it for subsequent ordered extents.  Previously we'd fall through and try to
reserve metadata bytes for this, then we'd just steal the full reservation from
the delalloc_block_rsv, and if that didn't have enough space we'd steal the full
reservation from the global reserve.  The problem with this is we can easily
just return ENOSPC and fallback to updating the inode item directly.  In the
worst case (assuming 4k nodesize) we'd steal 64kib from the global reserve if we
fall all the way through, however if we just fallback and update the inode
directly we'd only steal 4k * BTRFS_PATH_MAX in the worst case which is 32kib.

We would have also just added the extent item for the inode so we likely will
have already cow'ed down most of the way to the leaf containing the inode item,
so we are more often than not only need one or two nodesize's worth of
reservations.  Given the reservation for the extent itself is also a worst case
we will likely already have space to cover the inode update.

This change will make us behave better in the theoretical worst case, and much
better in the case that we don't have our reservation and cannot reserve more
metadata.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/delayed-inode.c