btrfs: shrink delalloc fixes

Hello,

I backported the patch to switch us to using sync_inode() to our kernel inside Facebook to fix a deadlock when using the async delalloc shrinker threads. This uncovered a bunch of problems with how we shrink delalloc, as we use -o compress-force, and thus everything goes through the async compression threads.

I ripped out the async pages stuff because originally I had switched us to just writing the whole inode. This caused a performance regression, and so I switched us to calling sync_inode() twice to handle the async extent case. The problem is that sync_inode() can skip writing inodes sometimes, and thus we weren't properly waiting on the async helpers. We really do need to wait for the async delalloc pages to go down before continuing to shrink delalloc. There was also a race in how we woke up the async delalloc pages waiter which could be problematic.

And then finally there is our use of sync_inode(). It tries to be too clever for us, when in reality we want to make sure all pages are under writeback before we come back to the shrinking loop. I've added a small helper to give us this flexibilty and have switched us to that helper.

With these patches, and others that will be sent separately, the early ENOSPC problems we were experiencing have been eliminated. Thanks,

Josef Bacik (4):
btrfs: wait on async extents when flushing delalloc
btrfs: wake up async_delalloc_pages waiters after submit
fs: add a filemap_fdatawrite_wbc helper
btrfs: use the filemap_fdatawrite_wbc helper for delalloc shrinking

 fs/btrfs/inode.c      | 16 ++++++----------
 fs/btrfs/space-info.c | 33 +++++++++++++++++++++++++++++++++
 include/linux/fs.h    |  2 ++
 mm/filemap.c          | 29 ++++++++++++++++++++++++-----
 4 files changed, 65 insertions(+), 15 deletions(-)

2.26.3