summaryrefslogtreecommitdiff
path: root/fs/notify/Makefile
diff options
context:
space:
mode:
authorJosef Bacik <josef@redhat.com>2011-09-26 17:12:22 -0400
committerJosef Bacik <josef@redhat.com>2011-10-19 15:12:50 -0400
commit2bf64758fd6290797a5ce97d4b9c698a4ed1cbad (patch)
tree61c7cedc6d7870d288c11333596da6ec673fae95 /fs/notify/Makefile
parent8f6d7f4f45f18a5b669dbbf068c74b3d5be59dbf (diff)
Btrfs: allow us to overcommit our enospc reservations
One of the things that kills us is the fact that our ENOSPC reservations are horribly over the top in most normal cases. There isn't too much that can be done about this because when we are completely full we really need them to work like this so we don't under reserve. However if there is plenty of unallocated chunks on the disk we can use that to gauge how much we can overcommit. So this patch adds chunk free space accounting so we always know how much unallocated space we have. Then if we fail to make a reservation within our allocated space, check to see if we can overcommit. In the normal flushing case (like with delalloc metadata reservations) we'll take the free space and divide it by 2 if our metadata profile is setup for DUP or any of those, and then divide it by 8 to make sure we don't overcommit too much. Then if we're in a non-flushing case (we really need this reservation now!) we only limit ourselves to half of the free space. This makes this fio test [torrent] filename=torrent-test rw=randwrite size=4g ioengine=sync directory=/mnt/btrfs-test go from taking around 45 minutes to 10 seconds on my freshly formatted 3 TiB file system. This doesn't seem to break my other enospc tests, but could really use some more testing as this is a super scary change. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com>
Diffstat (limited to 'fs/notify/Makefile')
0 files changed, 0 insertions, 0 deletions