From patchwork Wed Jul 14 18:47:17 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 12377703 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2E2F9C11F6A for ; Wed, 14 Jul 2021 18:47:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1AB94613C9 for ; Wed, 14 Jul 2021 18:47:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230075AbhGNSu1 (ORCPT ); Wed, 14 Jul 2021 14:50:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240080AbhGNSuY (ORCPT ); Wed, 14 Jul 2021 14:50:24 -0400 Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C55D1C061765 for ; Wed, 14 Jul 2021 11:47:29 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id a10so1252694qvj.11 for ; Wed, 14 Jul 2021 11:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=NEIgkiTj4t3jttXcyN/5zz8YqcqMXxtRu1nEAsbHwxE=; b=p+t/WKtRaf1tvAClAUr+ZmzhvTPUK1x9+pxpPkUkK9ebhmfVYlIezYHVv5zK8FI0EC dOS9cdzvmSuG/oXQ7jwhUdwwolA2ZtTOQqP115r4SFQR8iaZUuNnF2phPKQTzCoKEqhs B63TppqB5ueS98zoW2li+i9GcNO+iokQJpwOKXm/lh0ruStga2kj1s3UONzCxtt//8lT o7lOzjkzs+i1M9TkP4ZfKWbmzokra4mxYfYEkM9VMSIH8OEPzN+n2/GmyilJ1F+3Ed+V OosJ8lNyw44JzjXumqin6jJvOJqoFGfMpNJPTjiCycK7kPks4XB9N50Wdk/Cu03ga2Qq uFcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=NEIgkiTj4t3jttXcyN/5zz8YqcqMXxtRu1nEAsbHwxE=; b=JEZuJIYNKG3X6nq1cAAobgLvdXPysLigBMxXlBVSGKry2FxtmMG+BRmfECIBPPYVT8 HEfmuRjJ1HHMVLM/lIOLHLt9s03vl9Ot4ZFHDVqtNzUewCvSSXO+o7oqDwuBd3B/FQ3u UCBu6BVvoJrurOGQxwJW3nCjqUAP5gPF3lEHTzrqyFFqTFdJEAjpme9YsLA6CZAdMj11 oyh/bjg/1j3tOteWo4Xd/xj7GhQFaj2Fs0aTcazKKUURZrFi/pAQK5k4i4rdlzR0CXrQ onElh0UHxK+P3kHZ9T9kK0avPYga18oK1AL7PgiZy4i77L8IQA+QsA4EZMAxHK27viwN t3Gw== X-Gm-Message-State: AOAM533tEMTS7rijFBRGV+fcydxAL3eCvng29Znfmaq2y9I79WEKdkpX aAuO+ayExL4TnXtiwEqPu0epVps+Y10FMQ1y X-Google-Smtp-Source: ABdhPJxZG8yTJlXAWrF55wKnikwJzt6/9WAyS7O1ymLPDGQRhmqUeoOYUjprybts1WfL3aPcNUKmsw== X-Received: by 2002:a05:6214:d08:: with SMTP id 8mr12484989qvh.32.1626288448684; Wed, 14 Jul 2021 11:47:28 -0700 (PDT) Received: from localhost (cpe-174-109-172-136.nc.res.rr.com. [174.109.172.136]) by smtp.gmail.com with ESMTPSA id 3sm1077237qtz.5.2021.07.14.11.47.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jul 2021 11:47:28 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com, linux-fsdevel@vger.kernel.org Cc: stable@vger.kernel.org, Nikolay Borisov Subject: [PATCH v3 1/9] btrfs: wake up async_delalloc_pages waiters after submit Date: Wed, 14 Jul 2021 14:47:17 -0400 Message-Id: X-Mailer: git-send-email 2.26.3 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org We use the async_delalloc_pages mechanism to make sure that we've completed our async work before trying to continue our delalloc flushing. The reason for this is we need to see any ordered extents that were created by our delalloc flushing. However we're waking up before we do the submit work, which is before we create the ordered extents. This is a pretty wide race window where we could potentially think there are no ordered extents and thus exit shrink_delalloc prematurely. Fix this by waking us up after we've done the work to create ordered extents. cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Reviewed-by: Nikolay Borisov --- fs/btrfs/inode.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index e6eb20987351..0f42864d5dd4 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -1290,11 +1290,6 @@ static noinline void async_cow_submit(struct btrfs_work *work) nr_pages = (async_chunk->end - async_chunk->start + PAGE_SIZE) >> PAGE_SHIFT; - /* atomic_sub_return implies a barrier */ - if (atomic_sub_return(nr_pages, &fs_info->async_delalloc_pages) < - 5 * SZ_1M) - cond_wake_up_nomb(&fs_info->async_submit_wait); - /* * ->inode could be NULL if async_chunk_start has failed to compress, * in which case we don't have anything to submit, yet we need to @@ -1303,6 +1298,11 @@ static noinline void async_cow_submit(struct btrfs_work *work) */ if (async_chunk->inode) submit_compressed_extents(async_chunk); + + /* atomic_sub_return implies a barrier */ + if (atomic_sub_return(nr_pages, &fs_info->async_delalloc_pages) < + 5 * SZ_1M) + cond_wake_up_nomb(&fs_info->async_submit_wait); } static noinline void async_cow_free(struct btrfs_work *work) From patchwork Wed Jul 14 18:47:18 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 12377699 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7B03C11F66 for ; Wed, 14 Jul 2021 18:47:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B2AEA60FF0 for ; Wed, 14 Jul 2021 18:47:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240088AbhGNSu0 (ORCPT ); Wed, 14 Jul 2021 14:50:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230080AbhGNSuX (ORCPT ); Wed, 14 Jul 2021 14:50:23 -0400 Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 49A7BC061760 for ; Wed, 14 Jul 2021 11:47:31 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id s193so2631373qke.4 for ; Wed, 14 Jul 2021 11:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=V4ubrhMWd+B6p1vRLOMjUxHyopfqP/FHLyRQu3oDcLY=; b=S6NwblJp3dnjLjHGn9zX4V85sRagMdhnxZ/iUQuC3387+NRiU3wedA0I+ZUSuTewiX eueUbH8kjRQemFTc4+Bs8ymOMe4YMz67x5ABFqn+S4k7OvOI1H7JZXULPkfQKR7MkFcf vrVMUojR0Yg6Sf1Z+mF+S37svGAz9hsBim1pI3XFz50tCKN0MvndJQND19e9qKbtsUF5 dbEVxnYdwCeC3XmW3eL22RAtW1v3jfQCT1I5BxbTh6h0ssLZ2Tjzpbq7UYu0eDIH1Spp Xr+WzEnGdexpsLmub3f/wnQcs1KUZEi02F8Xgrn9TvOIMNuRkakfdT8QMYIroKLhPXWo mozg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=V4ubrhMWd+B6p1vRLOMjUxHyopfqP/FHLyRQu3oDcLY=; b=QEbN7JhFJNnzGKn8dc23MU6CI6guyt1YB/nWDo27QKo9n2jxKV5GoBDVMcTyNU8DSQ lreu9ufPeggk1NYPHpiLmrseZPnxHByOQrgqG6Yg7WgQO12vKy+UpPFQuwFimKwo4Km6 0lk58z+KYzsiGTEw3StkEHw7N5cTW7PcHx1PqGLzSLyKf6IxluUH6vvkX3wS5etcv6lZ enezhLTJp6tYBBVxIgJXwufWHj/S76jZFMYy19z4dKfZdlH92rIvYr6/0wUW8jjbJRmb FnxiZRbsM0u7tNeKqLUtER4slKL70wnghAHLFs8PaXlVmwGSUy+6jz44RJTqh+niwRjZ 3twg== X-Gm-Message-State: AOAM533Wo9xVWhmxsCSJp8DD8yIB/gFZvCt4vPqL8YeBshdjJJWppkFL y2mYH7ekw/BMqvPlvdtc226+KGI3afrhA/Mf X-Google-Smtp-Source: ABdhPJyggr0ygazjtNNGcDthUTyPyH/J4WwnAF7T+R9gBzVWtpp9sixoYYItBi2D2HeZgEhSh5kjZg== X-Received: by 2002:a05:620a:16b7:: with SMTP id s23mr11649898qkj.495.1626288450258; Wed, 14 Jul 2021 11:47:30 -0700 (PDT) Received: from localhost (cpe-174-109-172-136.nc.res.rr.com. [174.109.172.136]) by smtp.gmail.com with ESMTPSA id 197sm1421633qkn.64.2021.07.14.11.47.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jul 2021 11:47:29 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com, linux-fsdevel@vger.kernel.org Subject: [PATCH v3 2/9] btrfs: include delalloc related info in dump space info tracepoint Date: Wed, 14 Jul 2021 14:47:18 -0400 Message-Id: <8bdbea6af922d952247196f999610bc45bc38071.1626288241.git.josef@toxicpanda.com> X-Mailer: git-send-email 2.26.3 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org In order to debug delalloc flushing issues I added delalloc_bytes and ordered_bytes to this tracepoint to see if they were non-zero when we were ENOSPC'ing. This was valuable for me and showed me cases where we weren't waiting on ordered extents properly. In order to add this to the tracepoint we need to take away the const modifier for fs_info, as percpu_sum_counter_positive() will change the counter when it adds up the percpu buckets. This is needed to make sure we're getting accurate information at these tracepoints, as the wrong information could send us down the wrong path when debugging problems. Signed-off-by: Josef Bacik --- include/trace/events/btrfs.h | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/include/trace/events/btrfs.h b/include/trace/events/btrfs.h index c7237317a8b9..a87953e74573 100644 --- a/include/trace/events/btrfs.h +++ b/include/trace/events/btrfs.h @@ -2037,7 +2037,7 @@ TRACE_EVENT(btrfs_convert_extent_bit, ); DECLARE_EVENT_CLASS(btrfs_dump_space_info, - TP_PROTO(const struct btrfs_fs_info *fs_info, + TP_PROTO(struct btrfs_fs_info *fs_info, const struct btrfs_space_info *sinfo), TP_ARGS(fs_info, sinfo), @@ -2057,6 +2057,8 @@ DECLARE_EVENT_CLASS(btrfs_dump_space_info, __field( u64, delayed_refs_reserved ) __field( u64, delayed_reserved ) __field( u64, free_chunk_space ) + __field( u64, delalloc_bytes ) + __field( u64, ordered_bytes ) ), TP_fast_assign_btrfs(fs_info, @@ -2074,6 +2076,8 @@ DECLARE_EVENT_CLASS(btrfs_dump_space_info, __entry->delayed_refs_reserved = fs_info->delayed_refs_rsv.reserved; __entry->delayed_reserved = fs_info->delayed_block_rsv.reserved; __entry->free_chunk_space = atomic64_read(&fs_info->free_chunk_space); + __entry->delalloc_bytes = percpu_counter_sum_positive(&fs_info->delalloc_bytes); + __entry->ordered_bytes = percpu_counter_sum_positive(&fs_info->ordered_bytes); ), TP_printk_btrfs("flags=%s total_bytes=%llu bytes_used=%llu " @@ -2081,7 +2085,8 @@ DECLARE_EVENT_CLASS(btrfs_dump_space_info, "bytes_may_use=%llu bytes_readonly=%llu " "reclaim_size=%llu clamp=%d global_reserved=%llu " "trans_reserved=%llu delayed_refs_reserved=%llu " - "delayed_reserved=%llu chunk_free_space=%llu", + "delayed_reserved=%llu chunk_free_space=%llu " + "delalloc_bytes=%llu ordered_bytes=%llu", __print_flags(__entry->flags, "|", BTRFS_GROUP_FLAGS), __entry->total_bytes, __entry->bytes_used, __entry->bytes_pinned, __entry->bytes_reserved, @@ -2089,11 +2094,12 @@ DECLARE_EVENT_CLASS(btrfs_dump_space_info, __entry->reclaim_size, __entry->clamp, __entry->global_reserved, __entry->trans_reserved, __entry->delayed_refs_reserved, - __entry->delayed_reserved, __entry->free_chunk_space) + __entry->delayed_reserved, __entry->free_chunk_space, + __entry->delalloc_bytes, __entry->ordered_bytes) ); DEFINE_EVENT(btrfs_dump_space_info, btrfs_done_preemptive_reclaim, - TP_PROTO(const struct btrfs_fs_info *fs_info, + TP_PROTO(struct btrfs_fs_info *fs_info, const struct btrfs_space_info *sinfo), TP_ARGS(fs_info, sinfo) ); From patchwork Wed Jul 14 18:47:19 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 12377701 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97D4FC11F68 for ; Wed, 14 Jul 2021 18:47:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 87E1D613C9 for ; Wed, 14 Jul 2021 18:47:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240096AbhGNSu0 (ORCPT ); Wed, 14 Jul 2021 14:50:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240079AbhGNSuY (ORCPT ); Wed, 14 Jul 2021 14:50:24 -0400 Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB428C061764 for ; Wed, 14 Jul 2021 11:47:32 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id z25so2575842qto.12 for ; Wed, 14 Jul 2021 11:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=EpdgEcRiBqQsZrOSnIk/qayn286ESnYWwrM6gnsT55M=; b=vdlXEiXebSuhkKjwBpAIpgZ3LlMhHVhskWGVr159+4cRz0cwgUPfSWGu3ECkOSOKfF bCDl3gbl9GP1t8J8GPIdWpRF/Zj0DWZEQrvnMrZe1X21bHjd9wCBZVvt3uH34Imos7No 49w0BZYuxupZOO/auWGB5z8YbREYpqtWAE/55WQFbPjTMxT/sSEcZPSp8fXrf/JPxBnq uR8Ubag1J4XqHY79BKiz6YDoe4k7+pyhV+xAwQ1fjiBR4yB1q5PuZ8Sp7X5TgRIeWBjP 0xfWnHUv7xsLd6bud3cYYEBxOCv6f71cAzfKn7ZIOKdl+NzLjxBLziuIg1uYWBsfcPcy qaDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=EpdgEcRiBqQsZrOSnIk/qayn286ESnYWwrM6gnsT55M=; b=IedsTttYhFpmrZXalfwVKEG+QZODPfd7j711yHdBnawURE5Ox2LRzwNTNevWUokAoX dVBvPDaBFbd6CaqRnQiYqsFHbJtwe2z8HiBAZPj4rUgQLVZghPE+HrVetw1NvAD7i4D9 ap2jdUgeat5haLqmAreq3NmPj/mcWuEB5FNGYkmIEDoXoSRu1V+dWn/wwRzQOh4jWugt ZXYF4c/f1FLLdsccM5jtwwtefERwj2jBMYfIkp/JFSBqs4vEJHwkj8cpFQSSwCEr8MK8 1b1/TRJhvmHLtZGk5K0AELm5rCb67zXJhFDeCJrzijdt3wzPdm3DyyY+XISNfCHqIyUH y6mw== X-Gm-Message-State: AOAM531e2M14A5MGaGsPChOSssZoFLd4bNPfIN+7NVeYaGh4B4zFA7nK PW1Z2hS2s2C1Mj731f4T7vvDC+oq/+SUs4j7 X-Google-Smtp-Source: ABdhPJzMXWWzEW1xNgRG2YJ6Ri2c+pRxiSkNfTQbuAUVeuozGxwrmS5brLLpNVP4YFy5tTOkSmvteA== X-Received: by 2002:ac8:1347:: with SMTP id f7mr1455871qtj.70.1626288451514; Wed, 14 Jul 2021 11:47:31 -0700 (PDT) Received: from localhost (cpe-174-109-172-136.nc.res.rr.com. [174.109.172.136]) by smtp.gmail.com with ESMTPSA id s3sm1406472qke.85.2021.07.14.11.47.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jul 2021 11:47:31 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com, linux-fsdevel@vger.kernel.org Subject: [PATCH v3 3/9] btrfs: enable a tracepoint when we fail tickets Date: Wed, 14 Jul 2021 14:47:19 -0400 Message-Id: X-Mailer: git-send-email 2.26.3 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org When debugging early enospc problems it was useful to have a tracepoint where we failed all tickets so I could check the state of the enospc counters at failure time to validate my fixes. This adds the tracpoint so you can easily get that information. Signed-off-by: Josef Bacik --- fs/btrfs/space-info.c | 2 ++ include/trace/events/btrfs.h | 6 ++++++ 2 files changed, 8 insertions(+) diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c index 392997376a1c..af161eb808a2 100644 --- a/fs/btrfs/space-info.c +++ b/fs/btrfs/space-info.c @@ -825,6 +825,8 @@ static bool maybe_fail_all_tickets(struct btrfs_fs_info *fs_info, struct reserve_ticket *ticket; u64 tickets_id = space_info->tickets_id; + trace_btrfs_fail_all_tickets(fs_info, space_info); + if (btrfs_test_opt(fs_info, ENOSPC_DEBUG)) { btrfs_info(fs_info, "cannot satisfy tickets, dumping space info"); __btrfs_dump_space_info(fs_info, space_info); diff --git a/include/trace/events/btrfs.h b/include/trace/events/btrfs.h index a87953e74573..d754c6ec1797 100644 --- a/include/trace/events/btrfs.h +++ b/include/trace/events/btrfs.h @@ -2104,6 +2104,12 @@ DEFINE_EVENT(btrfs_dump_space_info, btrfs_done_preemptive_reclaim, TP_ARGS(fs_info, sinfo) ); +DEFINE_EVENT(btrfs_dump_space_info, btrfs_fail_all_tickets, + TP_PROTO(struct btrfs_fs_info *fs_info, + const struct btrfs_space_info *sinfo), + TP_ARGS(fs_info, sinfo) +); + TRACE_EVENT(btrfs_reserve_ticket, TP_PROTO(const struct btrfs_fs_info *fs_info, u64 flags, u64 bytes, u64 start_ns, int flush, int error), From patchwork Wed Jul 14 18:47:20 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 12377705 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED704C07E9A for ; Wed, 14 Jul 2021 18:47:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B3FB261260 for ; Wed, 14 Jul 2021 18:47:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240109AbhGNSu2 (ORCPT ); Wed, 14 Jul 2021 14:50:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230080AbhGNSu0 (ORCPT ); Wed, 14 Jul 2021 14:50:26 -0400 Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 19914C061760 for ; Wed, 14 Jul 2021 11:47:34 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id p202so2598554qka.12 for ; Wed, 14 Jul 2021 11:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=nfMkZOCop8rCTuWPUwcOk31VcZ9PT/ircxMz2xSNZAU=; b=IwiHhNV3l/UEgD9whti5lVVACGaczf1jo57Ss1JEf3gSmq0fhgqReJcT3LMVOP1a9L lumz/2SOxWy7+pAU7AVONMuRzgBkU+qpEpFp336RHsjA705cFqCsObOJxJNG4WORfCzI Y9Jd3+ZP7rCivrNHg0SW7cgYuijke9k5I01AqBITHKHOU9WW0ZwgZ71XRZA1a1qq2okP Q+UUjI9aLsqQeM1wcafqZMHApQS1YxcqZiq9qpoVMWjijKYcHhRtokCWppuSpTMe4Xwb v1Juv5gZdvWte8tjA2dgMMwlMdQOcSTlptb9sSE0Td2TkI0DrRq+0xsgAJ8U2JUAVTAV rdjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=nfMkZOCop8rCTuWPUwcOk31VcZ9PT/ircxMz2xSNZAU=; b=JKY+YW7RKcl9BtUSTMrif12MzVz6zPe7BgRp7ZeEYgKs5nUImj6oD3kLWVkmsSWTmv NBpGs1LHRJi5oP96+870dFcqDcwRplz2qMiuwHYFKJYxc6ZqOcbZnKxTKrqWVUEBbKT+ lTue7DPDKkQ0abL9tcd/byJMdDYmO+IaR6hqlItw+xxoZOw3p4v7YGy0RPioGtHmgCwm E0bR8BOeMBsivJuPOqKO1T5p+qfNYlOd2hVIBHcyh3mwGIPjsH6ey7smw7B0h1Kn1WjE b7lhFIV+1UustHyaUjM/SLcyjXlxyEl2lG0EZLplKCWIyJCqZjlmz2xmNGZnuRcb5JvU DV+A== X-Gm-Message-State: AOAM531s5nhxbFQy8Zim1oLO0k8/eXYRJOzI1MZePFiXT28wufESDy68 ndb67dJrq5ZyEg5gl85MwU5iRt/tKX6LCeAJ X-Google-Smtp-Source: ABdhPJyhvidQvC8DnXNrL68MUooA9iRV9+8wJnjGK5T+vZpH7D5dEeEfPxYsoYVtQ73vues3H30gqQ== X-Received: by 2002:a37:4685:: with SMTP id t127mr11397515qka.384.1626288452995; Wed, 14 Jul 2021 11:47:32 -0700 (PDT) Received: from localhost (cpe-174-109-172-136.nc.res.rr.com. [174.109.172.136]) by smtp.gmail.com with ESMTPSA id k24sm1397062qkk.25.2021.07.14.11.47.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jul 2021 11:47:32 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com, linux-fsdevel@vger.kernel.org Cc: stable@vger.kernel.org Subject: [PATCH v3 4/9] btrfs: handle shrink_delalloc pages calculation differently Date: Wed, 14 Jul 2021 14:47:20 -0400 Message-Id: <725c04f4a0f9d495e0ba56b7fe1276c6bc4bc9a1.1626288241.git.josef@toxicpanda.com> X-Mailer: git-send-email 2.26.3 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org We have been hitting some early ENOSPC issues in production with more recent kernels, and I tracked it down to us simply not flushing delalloc as aggressively as we should be. With tracing I was seeing us failing all tickets with all of the block rsvs at or around 0, with very little pinned space, but still around 120MiB of outstanding bytes_may_used. Upon further investigation I saw that we were flushing around 14 pages per shrink call for delalloc, despite having around 2GiB of delalloc outstanding. Consider the example of a 8 way machine, all CPUs trying to create a file in parallel, which at the time of this commit requires 5 items to do. Assuming a 16k leaf size, we have 10MiB of total metadata reclaim size waiting on reservations. Now assume we have 128MiB of delalloc outstanding. With our current math we would set items to 20, and then set to_reclaim to 20 * 256k, or 5MiB. Assuming that we went through this loop all 3 times, for both FLUSH_DELALLOC and FLUSH_DELALLOC_WAIT, and then did the full loop twice, we'd only flush 60MiB of the 128MiB delalloc space. This could leave a fair bit of delalloc reservations still hanging around by the time we go to ENOSPC out all the remaining tickets. Fix this two ways. First, change the calculations to be a fraction of the total delalloc bytes on the system. Prior to this change we were calculating based on dirty inodes so our math made more sense, now it's just completely unrelated to what we're actually doing. Second add a FLUSH_DELALLOC_FULL state, that we hold off until we've gone through the flush states at least once. This will empty the system of all delalloc so we're sure to be truly out of space when we start failing tickets. I'm tagging stable 5.10 and forward, because this is where we started using the page stuff heavily again. This affects earlier kernel versions as well, but would be a pain to backport to them as the flushing mechanisms aren't the same. CC: stable@vger.kernel.org # 5.10+ Signed-off-by: Josef Bacik --- fs/btrfs/ctree.h | 9 ++++---- fs/btrfs/space-info.c | 40 +++++++++++++++++++++++++----------- include/trace/events/btrfs.h | 1 + 3 files changed, 34 insertions(+), 16 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index d7ef4d7d2c1a..232ff1a49ca6 100644 --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -2783,10 +2783,11 @@ enum btrfs_flush_state { FLUSH_DELAYED_REFS = 4, FLUSH_DELALLOC = 5, FLUSH_DELALLOC_WAIT = 6, - ALLOC_CHUNK = 7, - ALLOC_CHUNK_FORCE = 8, - RUN_DELAYED_IPUTS = 9, - COMMIT_TRANS = 10, + FLUSH_DELALLOC_FULL = 7, + ALLOC_CHUNK = 8, + ALLOC_CHUNK_FORCE = 9, + RUN_DELAYED_IPUTS = 10, + COMMIT_TRANS = 11, }; int btrfs_subvolume_reserve_metadata(struct btrfs_root *root, diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c index af161eb808a2..1a7e44dd0ba7 100644 --- a/fs/btrfs/space-info.c +++ b/fs/btrfs/space-info.c @@ -494,6 +494,11 @@ static void shrink_delalloc(struct btrfs_fs_info *fs_info, long time_left; int loops; + delalloc_bytes = percpu_counter_sum_positive(&fs_info->delalloc_bytes); + ordered_bytes = percpu_counter_sum_positive(&fs_info->ordered_bytes); + if (delalloc_bytes == 0 && ordered_bytes == 0) + return; + /* Calc the number of the pages we need flush for space reservation */ if (to_reclaim == U64_MAX) { items = U64_MAX; @@ -501,22 +506,21 @@ static void shrink_delalloc(struct btrfs_fs_info *fs_info, /* * to_reclaim is set to however much metadata we need to * reclaim, but reclaiming that much data doesn't really track - * exactly, so increase the amount to reclaim by 2x in order to - * make sure we're flushing enough delalloc to hopefully reclaim - * some metadata reservations. + * exactly. What we really want to do is reclaim full inode's + * worth of reservations, however that's not available to us + * here. We will take a fraction of the delalloc bytes for our + * flushing loops and hope for the best. Delalloc will expand + * the amount we write to cover an entire dirty extent, which + * will reclaim the metadata reservation for that range. If + * it's not enough subsequent flush stages will be more + * aggressive. */ + to_reclaim = max(to_reclaim, delalloc_bytes >> 3); items = calc_reclaim_items_nr(fs_info, to_reclaim) * 2; - to_reclaim = items * EXTENT_SIZE_PER_ITEM; } trans = (struct btrfs_trans_handle *)current->journal_info; - delalloc_bytes = percpu_counter_sum_positive( - &fs_info->delalloc_bytes); - ordered_bytes = percpu_counter_sum_positive(&fs_info->ordered_bytes); - if (delalloc_bytes == 0 && ordered_bytes == 0) - return; - /* * If we are doing more ordered than delalloc we need to just wait on * ordered extents, otherwise we'll waste time trying to flush delalloc @@ -596,8 +600,11 @@ static void flush_space(struct btrfs_fs_info *fs_info, break; case FLUSH_DELALLOC: case FLUSH_DELALLOC_WAIT: + case FLUSH_DELALLOC_FULL: + if (state == FLUSH_DELALLOC_FULL) + num_bytes = U64_MAX; shrink_delalloc(fs_info, space_info, num_bytes, - state == FLUSH_DELALLOC_WAIT, for_preempt); + state != FLUSH_DELALLOC, for_preempt); break; case FLUSH_DELAYED_REFS_NR: case FLUSH_DELAYED_REFS: @@ -907,6 +914,14 @@ static void btrfs_async_reclaim_metadata_space(struct work_struct *work) commit_cycles--; } + /* + * We do not want to empty the system of delalloc unless we're + * under heavy pressure, so allow one trip through the flushing + * logic before we start doing a FLUSH_DELALLOC_FULL. + */ + if (flush_state == FLUSH_DELALLOC_FULL && !commit_cycles) + flush_state++; + /* * We don't want to force a chunk allocation until we've tried * pretty hard to reclaim space. Think of the case where we @@ -1070,7 +1085,7 @@ static void btrfs_preempt_reclaim_metadata_space(struct work_struct *work) * so if we now have space to allocate do the force chunk allocation. */ static const enum btrfs_flush_state data_flush_states[] = { - FLUSH_DELALLOC_WAIT, + FLUSH_DELALLOC_FULL, RUN_DELAYED_IPUTS, COMMIT_TRANS, ALLOC_CHUNK_FORCE, @@ -1159,6 +1174,7 @@ static const enum btrfs_flush_state evict_flush_states[] = { FLUSH_DELAYED_REFS, FLUSH_DELALLOC, FLUSH_DELALLOC_WAIT, + FLUSH_DELALLOC_FULL, ALLOC_CHUNK, COMMIT_TRANS, }; diff --git a/include/trace/events/btrfs.h b/include/trace/events/btrfs.h index d754c6ec1797..e21744a3cdb6 100644 --- a/include/trace/events/btrfs.h +++ b/include/trace/events/btrfs.h @@ -94,6 +94,7 @@ struct btrfs_space_info; EM( FLUSH_DELAYED_ITEMS, "FLUSH_DELAYED_ITEMS") \ EM( FLUSH_DELALLOC, "FLUSH_DELALLOC") \ EM( FLUSH_DELALLOC_WAIT, "FLUSH_DELALLOC_WAIT") \ + EM( FLUSH_DELALLOC_FULL, "FLUSH_DELALLOC_FULL") \ EM( FLUSH_DELAYED_REFS_NR, "FLUSH_DELAYED_REFS_NR") \ EM( FLUSH_DELAYED_REFS, "FLUSH_ELAYED_REFS") \ EM( ALLOC_CHUNK, "ALLOC_CHUNK") \ From patchwork Wed Jul 14 18:47:21 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 12377707 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 808A0C11F67 for ; Wed, 14 Jul 2021 18:47:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6556E61260 for ; Wed, 14 Jul 2021 18:47:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240080AbhGNSua (ORCPT ); Wed, 14 Jul 2021 14:50:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240075AbhGNSu1 (ORCPT ); Wed, 14 Jul 2021 14:50:27 -0400 Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6030AC061760 for ; Wed, 14 Jul 2021 11:47:35 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id 23so2664104qke.0 for ; Wed, 14 Jul 2021 11:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=e0vy2jqlq1xQtqe0Mfyhc5JVDQPE9FbGEnEvInBjRpI=; b=FK33z2MNOmGIAP0W2yTG17N8zGFM3orvDognSSjDnJd4xA0k80GgTFu8A8AamfRunK f8+JuZDg7lkjYf6+/YJHiraNLBpYyuV4d1PzTFxLVROGa3XGzCdDh+U1JMXBzY5KlthE qGj5T7WlVGF8/glqwOTLSFVz2cKiJzdhc2cY2l6HwXgbLTazs5GCDIqGDj3LdfyJCCTe pAhW5peF6WTUFqEkpzAdjHmvrZj5G2srNa73X2LPdfYtNixnV0DG3OojPzjMg40eyd2p KggEaL91UzmdBP8iRdnJbbnk1UIC9O60O33VBtrvbSKujq6LmBOwkFG/9gyNxps6mwW3 m4BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=e0vy2jqlq1xQtqe0Mfyhc5JVDQPE9FbGEnEvInBjRpI=; b=R6fJ1N7PGXnRpXQN8jlyDVFm51W3bdLeIFeVLYIUhxHEtBFzf52K69EngwS1CMUHcS QQWr3HxjskN1ve99SewKX7SmILdgDVBNoZOZaMAlUa49m7heL6Ps9oJ5g9+hik+h6eCL 3i1rfZNA5rQgy9eCVQTT/Q/Ko9C77NArZvd8oeUMe4tzpIfvdeHjKGzEcnepBBJhQmTw rr5xkoltVq95bNuTk3e25UI3AAwVs5Cyn1omFgA0KIILp6oymXdheKvDorHYjF8e3vUf 40O5eHK58M0UZrpvYu+sHeV6T3aJEmfLtzm//5PuA3WCoCPI0CDthvG1wRHBiSrNB2Ej RSsQ== X-Gm-Message-State: AOAM533Ckf5WgX2k5VQnZFcKbhkEF9qV/V25VMBvq3vQF13vLSLnQeTa +e6KQR4YHJ6upQRsCVP6jNeGKSz/CxeKUgSE X-Google-Smtp-Source: ABdhPJxjym0N7bnFOb4MhpUAUvBcDIIew6nOEDqozi/g8J2Ri/vYIi2ctjTCQLSJAIxI0xzH5HzIew== X-Received: by 2002:a37:7e46:: with SMTP id z67mr11294939qkc.417.1626288454361; Wed, 14 Jul 2021 11:47:34 -0700 (PDT) Received: from localhost (cpe-174-109-172-136.nc.res.rr.com. [174.109.172.136]) by smtp.gmail.com with ESMTPSA id m6sm1057089qtx.9.2021.07.14.11.47.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jul 2021 11:47:34 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com, linux-fsdevel@vger.kernel.org Subject: [PATCH v3 5/9] btrfs: wait on async extents when flushing delalloc Date: Wed, 14 Jul 2021 14:47:21 -0400 Message-Id: <30dc1fa25489b1bae3ad44f290249ec9dbb9df6a.1626288241.git.josef@toxicpanda.com> X-Mailer: git-send-email 2.26.3 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org I've been debugging an early ENOSPC problem in production and finally root caused it to this problem. When we switched to the per-inode in 38d715f494f2 ("btrfs: use btrfs_start_delalloc_roots in shrink_delalloc") I pulled out the async extent handling, because we were doing the correct thing by calling filemap_flush() if we had async extents set. This would properly wait on any async extents by locking the page in the second flush, thus making sure our ordered extents were properly set up. However when I switched us back to page based flushing, I used sync_inode(), which allows us to pass in our own wbc. The problem here is that sync_inode() is smarter than the filemap_* helpers, it tries to avoid calling writepages at all. This means that our second call could skip calling do_writepages altogether, and thus not wait on the pagelock for the async helpers. This means we could come back before any ordered extents were created and then simply continue on in our flushing mechanisms and ENOSPC out when we have plenty of space to use. Fix this by putting back the async pages logic in shrink_delalloc. This allows us to bulk write out everything that we need to, and then we can wait in one place for the async helpers to catch up, and then wait on any ordered extents that are created. Fixes: e076ab2a2ca7 ("btrfs: shrink delalloc pages instead of full inodes") Signed-off-by: Josef Bacik --- fs/btrfs/inode.c | 4 ---- fs/btrfs/space-info.c | 40 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 0f42864d5dd4..e388153c4ae4 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -9714,10 +9714,6 @@ static int start_delalloc_inodes(struct btrfs_root *root, &work->work); } else { ret = sync_inode(inode, wbc); - if (!ret && - test_bit(BTRFS_INODE_HAS_ASYNC_EXTENT, - &BTRFS_I(inode)->runtime_flags)) - ret = sync_inode(inode, wbc); btrfs_add_delayed_iput(inode); if (ret || wbc->nr_to_write <= 0) goto out; diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c index 1a7e44dd0ba7..9dcde8c97c43 100644 --- a/fs/btrfs/space-info.c +++ b/fs/btrfs/space-info.c @@ -533,9 +533,49 @@ static void shrink_delalloc(struct btrfs_fs_info *fs_info, while ((delalloc_bytes || ordered_bytes) && loops < 3) { u64 temp = min(delalloc_bytes, to_reclaim) >> PAGE_SHIFT; long nr_pages = min_t(u64, temp, LONG_MAX); + int async_pages; btrfs_start_delalloc_roots(fs_info, nr_pages, true); + /* + * We need to make sure any outstanding async pages are now + * processed before we continue. This is because things like + * sync_inode() try to be smart and skip writing if the inode is + * marked clean. We don't use filemap_fwrite for flushing + * because we want to control how many pages we write out at a + * time, thus this is the only safe way to make sure we've + * waited for outstanding compressed workers to have started + * their jobs and thus have ordered extents set up properly. + * + * This exists because we do not want to wait for each + * individual inode to finish its async work, we simply want to + * start the IO on everybody, and then come back here and wait + * for all of the async work to catch up. Once we're done with + * that we know we'll have ordered extents for everything and we + * can decide if we wait for that or not. + * + * If we choose to replace this in the future, make absolutely + * sure that the proper waiting is being done in the async case, + * as there have been bugs in that area before. + */ + async_pages = atomic_read(&fs_info->async_delalloc_pages); + if (!async_pages) + goto skip_async; + + /* + * We don't want to wait forever, if we wrote less pages in this + * loop than we have outstanding, only wait for that number of + * pages, otherwise we can wait for all async pages to finish + * before continuing. + */ + if (async_pages > nr_pages) + async_pages -= nr_pages; + else + async_pages = 0; + wait_event(fs_info->async_submit_wait, + atomic_read(&fs_info->async_delalloc_pages) <= + async_pages); +skip_async: loops++; if (wait_ordered && !trans) { btrfs_wait_ordered_roots(fs_info, items, 0, (u64)-1); From patchwork Wed Jul 14 18:47:22 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 12377709 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60973C11F68 for ; Wed, 14 Jul 2021 18:47:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 45F4F60FF0 for ; Wed, 14 Jul 2021 18:47:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240079AbhGNSuc (ORCPT ); Wed, 14 Jul 2021 14:50:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240100AbhGNSu2 (ORCPT ); Wed, 14 Jul 2021 14:50:28 -0400 Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B9EF2C061760 for ; Wed, 14 Jul 2021 11:47:36 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id s193so2631704qke.4 for ; Wed, 14 Jul 2021 11:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=vcIKkUHDUMaUNxFd2j3gUaKSKz8MliVlhmquY+JHLoY=; b=lQj78Zf63qxlNkMkUh3NAtWpK7o0ZfxSoZfNSFGJUgDawTJjppaWcxmmyLXq23b5Uw czSlmrehECOrHHSdBE8SNl1uIx9aRxGTrCbILoowHC3JNLel5tD+p3Td+fnJRNmY8c5A AyS1fb7gZ+IdckWjijLg8RwP5MEVKNsKNufEkiMT9yvE2WqW/AnryiOHTNgqMtf9hLxZ 9XQ9Ux+QbUqdWvNjguPhpTKMCa79qHl425VWdl2F1sTSSknoe1HNYRn2XAv8mSx9FQjQ v12elPGGDVf9AbWfd5IX3KI+4RCHQoSaGCPEfyT591+k1tuVv0bU0QQ7N3KD9CGqb2l0 bKxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=vcIKkUHDUMaUNxFd2j3gUaKSKz8MliVlhmquY+JHLoY=; b=n0/vkwdPm/uXM944O/Qa+6GCk9tbZHFeLUTJNCB6jw5C35zReRJfLf5bya4OYeL9WH Giqw2RsDXdpSuVcWg6NIYOWj9r2KysGhY7+ne1yzaUKAvUrcjZwFIb/cqyxpT1Gyq/0A WuT6z5e9w8YnksmUY/xGV/KrgPDEZwYcScFJ/JK0F2Vw7M7rzXv97Ogl2Z6Ri/uVC172 MQvRBbcjdeje4VaSK9HepHzn8YK4Dk+RGTPbEHHs5vp3ZKxjx6T6nEB7IgC3WkDmCegU u1OSwMMxWjSVxCpCyu+YlVjGSxea/zAlM1/Dq5OsOuvR2rbWgsRs6ABkGfzIPYDQPg5y +9pg== X-Gm-Message-State: AOAM532/u6nvtzZh3EB+uX+pPYmxxQq4gjAShycA9enK0x0mxfdZZd1/ nLTfYF0YjWMtDay5HHP0ZK8SBGBOlalPYRPS X-Google-Smtp-Source: ABdhPJwrcsMqMo+umcx1D8jfi9BI/Qh+9Dq9C68/MCcJnUujU3NVfdVQ034Vod6IszzfoHml9tPZzA== X-Received: by 2002:a37:847:: with SMTP id 68mr11453978qki.112.1626288455720; Wed, 14 Jul 2021 11:47:35 -0700 (PDT) Received: from localhost (cpe-174-109-172-136.nc.res.rr.com. [174.109.172.136]) by smtp.gmail.com with ESMTPSA id d2sm1067358qto.91.2021.07.14.11.47.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jul 2021 11:47:35 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com, linux-fsdevel@vger.kernel.org Cc: Nikolay Borisov Subject: [PATCH v3 6/9] fs: add a filemap_fdatawrite_wbc helper Date: Wed, 14 Jul 2021 14:47:22 -0400 Message-Id: <1a353b1b013f616c2798526a8d21bb0cd609c25f.1626288241.git.josef@toxicpanda.com> X-Mailer: git-send-email 2.26.3 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Btrfs sometimes needs to flush dirty pages on a bunch of dirty inodes in order to reclaim metadata reservations. Unfortunately most helpers in this area are too smart for us 1) The normal filemap_fdata* helpers only take range and sync modes, and don't give any indication of how much was written, so we can only flush full inodes, which isn't what we want in most cases. 2) The normal writeback path requires us to have the s_umount sem held, but we can't unconditionally take it in this path because we could deadlock. 3) The normal writeback path also skips inodes with I_SYNC set if we write with WB_SYNC_NONE. This isn't the behavior we want under heavy ENOSPC pressure, we want to actually make sure the pages are under writeback before returning, and if another thread is in the middle of writing the file we may return before they're under writeback and miss our ordered extents and not properly wait for completion. 4) sync_inode() uses the normal writeback path and has the same problem as #3. What we really want is to call do_writepages() with our wbc. This way we can make sure that writeback is actually started on the pages, and we can control how many pages are written as a whole as we write many inodes using the same wbc. Accomplish this with a new helper that does just that so we can use it for our ENOSPC flushing infrastructure. Signed-off-by: Josef Bacik Reviewed-by: Nikolay Borisov Reviewed-by: Christoph Hellwig --- include/linux/fs.h | 2 ++ mm/filemap.c | 35 ++++++++++++++++++++++++++--------- 2 files changed, 28 insertions(+), 9 deletions(-) diff --git a/include/linux/fs.h b/include/linux/fs.h index c3c88fdb9b2a..aace07f88b73 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -2886,6 +2886,8 @@ extern int filemap_fdatawrite_range(struct address_space *mapping, loff_t start, loff_t end); extern int filemap_check_errors(struct address_space *mapping); extern void __filemap_set_wb_err(struct address_space *mapping, int err); +extern int filemap_fdatawrite_wbc(struct address_space *mapping, + struct writeback_control *wbc); static inline int filemap_write_and_wait(struct address_space *mapping) { diff --git a/mm/filemap.c b/mm/filemap.c index 66f7e9fdfbc4..8395eafc178b 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -376,6 +376,31 @@ static int filemap_check_and_keep_errors(struct address_space *mapping) return -ENOSPC; return 0; } +/** + * filemap_fdatawrite_wbc - start writeback on mapping dirty pages in range + * @mapping: address space structure to write + * @wbc: the writeback_control controlling the writeout + * + * Call writepages on the mapping using the provided wbc to control the + * writeout. + * + * Return: %0 on success, negative error code otherwise. + */ +int filemap_fdatawrite_wbc(struct address_space *mapping, + struct writeback_control *wbc) +{ + int ret; + + if (!mapping_can_writeback(mapping) || + !mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) + return 0; + + wbc_attach_fdatawrite_inode(wbc, mapping->host); + ret = do_writepages(mapping, wbc); + wbc_detach_inode(wbc); + return ret; +} +EXPORT_SYMBOL(filemap_fdatawrite_wbc); /** * __filemap_fdatawrite_range - start writeback on mapping dirty pages in range @@ -397,7 +422,6 @@ static int filemap_check_and_keep_errors(struct address_space *mapping) int __filemap_fdatawrite_range(struct address_space *mapping, loff_t start, loff_t end, int sync_mode) { - int ret; struct writeback_control wbc = { .sync_mode = sync_mode, .nr_to_write = LONG_MAX, @@ -405,14 +429,7 @@ int __filemap_fdatawrite_range(struct address_space *mapping, loff_t start, .range_end = end, }; - if (!mapping_can_writeback(mapping) || - !mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) - return 0; - - wbc_attach_fdatawrite_inode(&wbc, mapping->host); - ret = do_writepages(mapping, &wbc); - wbc_detach_inode(&wbc); - return ret; + return filemap_fdatawrite_wbc(mapping, &wbc); } static inline int __filemap_fdatawrite(struct address_space *mapping, From patchwork Wed Jul 14 18:47:23 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 12377711 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B257AC07E9A for ; Wed, 14 Jul 2021 18:47:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9BE4A613CB for ; Wed, 14 Jul 2021 18:47:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240134AbhGNSuc (ORCPT ); Wed, 14 Jul 2021 14:50:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240075AbhGNSua (ORCPT ); Wed, 14 Jul 2021 14:50:30 -0400 Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37E30C061765 for ; Wed, 14 Jul 2021 11:47:38 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id d15so2577635qte.13 for ; Wed, 14 Jul 2021 11:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=JNekpPuEULpCMOwivjqUjmNvC4JFfFA0/dEwN2gvg5g=; b=MoDWOvkbNfmQlUXE94ddpWnR8t5gaHGSJ4yjF9hcFzocJuEMNyOZq0aFvxFDtDKwQy JJlphut81Z+PPnQONtSnYMFucGSF+zX9g2ecRjox/b5J8iOfTxCPI3kLisFrDnxpu+Zv 0aIORgxoKEB/NX5mVcFHFmXG8gS00we+YAcqhpKk0Dc0yxCGkb31gqbh+LxS86RCf/2A 1tobbeTjwZ22Ca8Z30PXaFFieWGlJ7AAQnZkQSyKqZX9ARa7ywKNticn3l4Vk/O3BOYK Jqw8NKCggtXwtHrNteh4kgvy+HsvNZp1nFibKdoGEJK4P+ONr8lTg2YhDx3H4zyvMCTA MPlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=JNekpPuEULpCMOwivjqUjmNvC4JFfFA0/dEwN2gvg5g=; b=g0NHdjGzUGAkZ6izj7Hk7AVOwyjI245CnJt0MdTLuNB8w+EA1eMjfdUrf6/C/sboYM PacEDmpC6f/QfLh9fYnJBuceABHBhf10EtsUkC8WXYB+vYP2Md1rGw7ilPONpsDV9hHA 2n0+ipVvv1sgJZAIyjLRT1lE83iT+lT4pg09BkfkPVSvhkXCFWtI9rx6NbBVPzv/n+LK XagbISSf2ORjggQrGGsx7Twglcclvn4PfOrXgvsoQZAPLTl/lpIhNyUZ9p3akdXvS9oA AhFjkEXLrxKoL81bY8z1i8cHfIp+mEkiynvVLnZSB8TXznBv5slgmg0MZKP2ftKFWkUo X3xg== X-Gm-Message-State: AOAM5311lg0SqKevsCX/2+MMzIRddKDXMb2kfTtGoOf+7WE0EWUXT9fb lVdS5OK251+BF6lPAJqs2QGjcF8mNGFdxSvN X-Google-Smtp-Source: ABdhPJydN+M0zPH+sop8KzTKtnIAH7/w63hbq9eWYwMhRgunXSjejkotX09tiVc2xvwuPFSi8j4uRw== X-Received: by 2002:ac8:5803:: with SMTP id g3mr10576731qtg.3.1626288457181; Wed, 14 Jul 2021 11:47:37 -0700 (PDT) Received: from localhost (cpe-174-109-172-136.nc.res.rr.com. [174.109.172.136]) by smtp.gmail.com with ESMTPSA id q184sm1389219qkd.35.2021.07.14.11.47.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jul 2021 11:47:36 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com, linux-fsdevel@vger.kernel.org Cc: Nikolay Borisov Subject: [PATCH v3 7/9] btrfs: use the filemap_fdatawrite_wbc helper for delalloc shrinking Date: Wed, 14 Jul 2021 14:47:23 -0400 Message-Id: <8b03a72d1b50931637b25daad29fb470fb08dde8.1626288241.git.josef@toxicpanda.com> X-Mailer: git-send-email 2.26.3 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org sync_inode() has some holes that can cause problems if we're under heavy ENOSPC pressure. If there's writeback running on a separate thread sync_inode() will skip writing the inode altogether. What we really want is to make sure writeback has been started on all the pages to make sure we can see the ordered extents and wait on them if appropriate. Switch to this new helper which will allow us to accomplish this and avoid ENOSPC'ing early. Signed-off-by: Josef Bacik Reviewed-by: Nikolay Borisov --- fs/btrfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index e388153c4ae4..b25c84aba743 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -9713,7 +9713,7 @@ static int start_delalloc_inodes(struct btrfs_root *root, btrfs_queue_work(root->fs_info->flush_workers, &work->work); } else { - ret = sync_inode(inode, wbc); + ret = filemap_fdatawrite_wbc(inode->i_mapping, wbc); btrfs_add_delayed_iput(inode); if (ret || wbc->nr_to_write <= 0) goto out; From patchwork Wed Jul 14 18:47:24 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 12377715 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E85A9C11F67 for ; Wed, 14 Jul 2021 18:47:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D988961260 for ; Wed, 14 Jul 2021 18:47:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240140AbhGNSuf (ORCPT ); Wed, 14 Jul 2021 14:50:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240132AbhGNSuc (ORCPT ); Wed, 14 Jul 2021 14:50:32 -0400 Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB201C061767 for ; Wed, 14 Jul 2021 11:47:39 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id o9so1537768qvu.5 for ; Wed, 14 Jul 2021 11:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=Xk61Zn1WGvZe9oDMxIvYakdXIuBAH34lTAxcJ/5AdLQ=; b=C/tU9se623yVpBbPLXzFaiqyH5+3u2knGq7aYpkFU2IFNxYVmHnF4ubtLLIKmwU/ba VlbsOEykpVidDiKXTPu6Qb7LUJZaVaqn52Y+TR2QnpmWqkl9VnSNlAy72Qd8jlucIIyP MpISqrlGcdEd/7u3jcvx2D/jc8mIA4quJUZjX8arcjY1lGE2FT0we3ncgNQzDrEORb2T 3zhKTtPOAjpwttUJ1ud+pLS7y3hxbKtk8zT/AvvrAJRnwPgsJ1+rimZ5tLXaRO02xQaX vuLa0Om6VU+knEndziipA/1eSWQpnf8bbRmwFwBydyhp3AeIuOAu8ijLOjOA+FrXcadY txVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Xk61Zn1WGvZe9oDMxIvYakdXIuBAH34lTAxcJ/5AdLQ=; b=pYwGYV/GV7JnycKVxM7HymQ8rahAY6+orjVUcKnKrK+boCskmwM8jgknAbdOvuEIQN 4l5naRASPD1zrfE1Qg9z37Ddx26UtQdCMs266uXlmbckkGAjgC6nrgPhtbc1fEYaBUXg Hhm0wXlet3HYOz3bUDoUZCfF4rMFiQgxPQ1jVsIVSDbmIuZYb8NJAC/JQhnjdqUkT9TZ LS5+HHjDI0tdYC7MXLB+R1v5zTrAWIX8oO3IEOwKej104epGLIBlSIAY5WGeMsYnN4dm jfJjnfX8YQy0Egc55b2eVIJHK9cRyuMcAzW1AUuRVMPmj1g+KFCRS8tMYu7J+Tn+TSj7 a8wQ== X-Gm-Message-State: AOAM530XydPT7jTAAREo1kEn4uqcDXQkzZ1yI3x4M7I+wn7JBVi9sIs9 uBMM7Xp78H0mhzY+bF30Ga1qS8ynQQniREwo X-Google-Smtp-Source: ABdhPJw3QYNBAYnp6RjYuMBTO3Ziqr3hboUy69T139RW4CtDXDHnTyQ2CAeV6P+JinJdVKM8Wjn9+g== X-Received: by 2002:ad4:5426:: with SMTP id g6mr12153276qvt.47.1626288458688; Wed, 14 Jul 2021 11:47:38 -0700 (PDT) Received: from localhost (cpe-174-109-172-136.nc.res.rr.com. [174.109.172.136]) by smtp.gmail.com with ESMTPSA id a190sm1474962qkf.9.2021.07.14.11.47.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jul 2021 11:47:38 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com, linux-fsdevel@vger.kernel.org Subject: [PATCH v3 8/9] 9p: migrate from sync_inode to filemap_fdatawrite_wbc Date: Wed, 14 Jul 2021 14:47:24 -0400 Message-Id: <696f89db6b30858af65749cafb72a896552cfc44.1626288241.git.josef@toxicpanda.com> X-Mailer: git-send-email 2.26.3 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org We're going to remove sync_inode, so migrate to filemap_fdatawrite_wbc instead. Signed-off-by: Josef Bacik Reviewed-by: Christoph Hellwig --- fs/9p/vfs_file.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c index 59c32c9b799f..6b64e8391f30 100644 --- a/fs/9p/vfs_file.c +++ b/fs/9p/vfs_file.c @@ -625,12 +625,7 @@ static void v9fs_mmap_vm_close(struct vm_area_struct *vma) p9_debug(P9_DEBUG_VFS, "9p VMA close, %p, flushing", vma); inode = file_inode(vma->vm_file); - - if (!mapping_can_writeback(inode->i_mapping)) - wbc.nr_to_write = 0; - - might_sleep(); - sync_inode(inode, &wbc); + filemap_fdatawrite_wbc(inode->i_mapping, &wbc); } From patchwork Wed Jul 14 18:47:25 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 12377713 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BAE57C07E9A for ; Wed, 14 Jul 2021 18:47:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A52E661260 for ; Wed, 14 Jul 2021 18:47:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240124AbhGNSue (ORCPT ); Wed, 14 Jul 2021 14:50:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240140AbhGNSud (ORCPT ); Wed, 14 Jul 2021 14:50:33 -0400 Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1DB92C061760 for ; Wed, 14 Jul 2021 11:47:41 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id p202so2598942qka.12 for ; Wed, 14 Jul 2021 11:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=4ITw8yYO9Mm2EpdRdd+ThoxB7QMMRcOH9aOSdlmSits=; b=0rpJPuMJ1jxhCoRWOAqTZd6zN/yZv7cGsws/5dyp0RPDk5yGbj3aBRIrSXG5WLEm6D AxDz3lCAE0gwoY2j8jeNE1ZTslQyXzhZeq4ftXR/so2xCGycfCU8TCs/rALNRCy0t68+ 4rGgxude/xhKypgjI6AKyq4JOrkW6Qf+pOaivIPu8dKAWPcAyF5zJPmwrztwNvkbriEV 81IrJhs75XLjqXeEu6aR0tyL7022zW1xMPmIeGdyGQIVcz5uBOqIaPvr/+RhuKWFKJAl xY5gJvSUE4YkhnXXrSkpOHzKTucWnyA07TJ+iBTYvZANoaeVKLZe9d8v1bVkwcczpOPO p9JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=4ITw8yYO9Mm2EpdRdd+ThoxB7QMMRcOH9aOSdlmSits=; b=dKaa0fAFHAcP3gAqV9sCE6DpFMo2a/uSmNk8v2hMs7qpJmhv0qGrTnzwvl/tghtrbF kAEoTXvy8p08ApMWcvAJPhrYKTM/GIdLkZVa1tSIj2ddT7cPZAbt4VmHqhDc3LGovqzl Yhi5/DriQV88SwQ3glYQsIznREjRUsLdNwvO7gNM4YiV+SfMrtI4nHbup4wsUifrbr5e pcQzKyR9Lwdl0P919eSFyJ+EKkqZYZaN1YKnPuGJ1CNyvztFL0WPu2SIopN7uqL0kgL1 EILGyloNcEbz7Tk9YYzCFK6LlbUyRB6+H0R4oi8JGhvLM+6jg3v30rtllAemyvTS1tCP /S7A== X-Gm-Message-State: AOAM531Yfp4bA5lagesXWlIn5PhQDlLRyVQTc4A/hPOBPWYJRoPGpyff 80lgvEsQB1RN5xHGr4snPhICqaZSTbsBdtOS X-Google-Smtp-Source: ABdhPJyHX8vfDY4LWszZXONESfbhQmTh2Tw5hDSZy+QhAXwh7eUT/aSKeHlokFDKQEnjjyU0cySG+A== X-Received: by 2002:a37:a413:: with SMTP id n19mr7494248qke.462.1626288460075; Wed, 14 Jul 2021 11:47:40 -0700 (PDT) Received: from localhost (cpe-174-109-172-136.nc.res.rr.com. [174.109.172.136]) by smtp.gmail.com with ESMTPSA id bk40sm1312434qkb.3.2021.07.14.11.47.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jul 2021 11:47:39 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com, linux-fsdevel@vger.kernel.org Subject: [PATCH v3 9/9] fs: kill sync_inode Date: Wed, 14 Jul 2021 14:47:25 -0400 Message-Id: <8c4c75ad09fb61114ee955829860ce8fd5e170ee.1626288241.git.josef@toxicpanda.com> X-Mailer: git-send-email 2.26.3 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Now that all users of sync_inode() have been deleted, remove sync_inode(). Signed-off-by: Josef Bacik Reviewed-by: Christoph Hellwig --- fs/fs-writeback.c | 19 +------------------ include/linux/fs.h | 1 - 2 files changed, 1 insertion(+), 19 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index e91980f49388..706dad22f735 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -2608,23 +2608,6 @@ int write_inode_now(struct inode *inode, int sync) } EXPORT_SYMBOL(write_inode_now); -/** - * sync_inode - write an inode and its pages to disk. - * @inode: the inode to sync - * @wbc: controls the writeback mode - * - * sync_inode() will write an inode and its pages to disk. It will also - * correctly update the inode on its superblock's dirty inode lists and will - * update inode->i_state. - * - * The caller must have a ref on the inode. - */ -int sync_inode(struct inode *inode, struct writeback_control *wbc) -{ - return writeback_single_inode(inode, wbc); -} -EXPORT_SYMBOL(sync_inode); - /** * sync_inode_metadata - write an inode to disk * @inode: the inode to sync @@ -2641,6 +2624,6 @@ int sync_inode_metadata(struct inode *inode, int wait) .nr_to_write = 0, /* metadata-only */ }; - return sync_inode(inode, &wbc); + return writeback_single_inode(inode, &wbc); } EXPORT_SYMBOL(sync_inode_metadata); diff --git a/include/linux/fs.h b/include/linux/fs.h index aace07f88b73..7c33e5414747 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -2458,7 +2458,6 @@ static inline void file_accessed(struct file *file) extern int file_modified(struct file *file); -int sync_inode(struct inode *inode, struct writeback_control *wbc); int sync_inode_metadata(struct inode *inode, int wait); struct file_system_type {