On Thu, Apr 25, 2019 at 04:52:47PM -0400, Josef Bacik wrote:
> When diagnosing a slowdown of generic/224 I noticed we were not doing
> anything when calling into shrink_delalloc(). This is because all
> writes in 224 are O_DIRECT, not delalloc, and thus our delalloc_bytes
> counter is 0, which short circuits most of the work inside of
> shrink_delalloc(). However O_DIRECT writes still consume metadata
> resources and generate ordered extents, which we can still wait on.
>
> Fix this by tracking outstandingn odirect write bytes, and use this as
> well as the delalloc byts counter to decide if we need to lookup and
> wait on any ordered extents. If we have more odirect writes than
> delalloc bytes we'll go ahead and wait on any ordered extents
> irregardless of our flush state as flushing delalloc is likely to not
> gain us anything.
Ok, that helps.
> Signed-off-by: Josef Bacik <jo...@toxicpanda.com>
> ---
> v1->v2:
> - updated the changelog
>
> fs/btrfs/ctree.h | 1 +
> fs/btrfs/disk-io.c | 15 ++++++++++++++-
> fs/btrfs/extent-tree.c | 17 +++++++++++++++--
> fs/btrfs/ordered-data.c | 9 ++++++++-
> 4 files changed, 38 insertions(+), 4 deletions(-)
>
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> index 7e774d48c48c..e293d74b2ead 100644
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -1016,6 +1016,7 @@ struct btrfs_fs_info {
> /* used to keep from writing metadata until there is a nice batch */
> struct percpu_counter dirty_metadata_bytes;
> struct percpu_counter delalloc_bytes;
> + struct percpu_counter odirect_bytes;
I've changed odirect to dio everywhere, as this is the common reference
to direct IO kernel code, O_DIRECT is for userspace.
