Btrfs: rework the overcommit logic to be based on the total size
authorJosef Bacik <jbacik@fusionio.com>
Wed, 6 Feb 2013 18:53:19 +0000 (13:53 -0500)
committerJosef Bacik <jbacik@fusionio.com>
Wed, 20 Feb 2013 17:59:32 +0000 (12:59 -0500)
commit70afa3998c9baed4186df38988246de1abdab56d
treef9f773ff12e15d974e55b3836aa0d9d666e80b0f
parent925396ecf251432d6d0f703a6cfd0cb9e651d936
Btrfs: rework the overcommit logic to be based on the total size

People have been complaining about random ENOSPC errors that will clear up
after a umount or just a given amount of time.  Chris was able to reproduce
this with stress.sh and lots of processes and so was I.  Basically the
overcommit stuff would really let us get out of hand, in my tests I saw up
to 30 gigs of outstanding reservations with only 2 gigs total of metadata
space.  This usually worked out fine but with so much outstanding
reservation the flushing stuff short circuits to make sure we don't hang
forever flushing when we really need ENOSPC.  Plus we allocate chunks in
order to alleviate the pressure, but this doesn't actually help us since we
only use the non-allocated area in our over commit logic.

So instead of basing overcommit on the amount of non-allocated space,
instead just do it based on how much total space we have, and then limit it
to the non-allocated space in case we are short on space to spill over into.
This allows us to have the same performance as well as no longer giving
random ENOSPC.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
fs/btrfs/extent-tree.c