From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0779D13590 for ; Mon, 28 Oct 2024 02:28:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 175BD6B0092; Sun, 27 Oct 2024 22:28:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 125B36B0093; Sun, 27 Oct 2024 22:28:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F07F36B0096; Sun, 27 Oct 2024 22:28:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D29386B0092 for ; Sun, 27 Oct 2024 22:28:29 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D10E4140693 for ; Mon, 28 Oct 2024 02:28:05 +0000 (UTC) X-FDA: 82721426676.16.23D889D Received: from out30-97.freemail.mail.aliyun.com (out30-97.freemail.mail.aliyun.com [115.124.30.97]) by imf29.hostedemail.com (Postfix) with ESMTP id 6D51412000E for ; Mon, 28 Oct 2024 02:27:51 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=DiEbDKaM; spf=pass (imf29.hostedemail.com: domain of jefflexu@linux.alibaba.com designates 115.124.30.97 as permitted sender) smtp.mailfrom=jefflexu@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730082298; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=VFQl1w/gX77WPMQusxQCra6sXMLdIY9lsYhIe+TixHg=; b=rBoo/iOIHLAYh2zi6cVCkzSR/ppZ9z7Yzh3O+G3EaDYXpxvGSsy2/OdBGZ2Moki6QxWXgX RDHc7Z01D0pRevspjZfTDvrRcPykpfeSdD2+rGCtxW3OoSdMvmAHc1U71MjKHkuk51bwXB hEwAiMSiYD0lofj28mR/YFC4KBV8l8Q= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=DiEbDKaM; spf=pass (imf29.hostedemail.com: domain of jefflexu@linux.alibaba.com designates 115.124.30.97 as permitted sender) smtp.mailfrom=jefflexu@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730082298; a=rsa-sha256; cv=none; b=271zph9Hy6fgWk57IfDRAN+REYfRaJkCXY9k4rXdbSwLJ95lHVxnm9Uh7wnqA52+J8nbia w6oNVyQzqK+/SoH9DjTDTX172ftV/3RxHeTxUptovT01uN1XJTmD9HCs6usDApyNOLlU/F WQSl4mnBS+WF0jOypx8ywAX+KaHrVuc= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1730082492; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=VFQl1w/gX77WPMQusxQCra6sXMLdIY9lsYhIe+TixHg=; b=DiEbDKaMlGuAIkz69NffOFno2nqXdG093I2MsZbOzLaAUIPrQJzeh9kTFuFacNnnQo/FFR5a/PB7mLHD8G7FdSG7RmwAjbOLc3MLYldqOUTShbEoY+WoJq0Yq3Oda+mbGZ0BVnFj2mgRHy/v5yycEI7sozpOvvbamDU7hx9qlNY= Received: from 30.221.148.132(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0WHz.MBB_1730082488 cluster:ay36) by smtp.aliyun-inc.com; Mon, 28 Oct 2024 10:28:09 +0800 Message-ID: <5825a89f-7994-4de5-aecb-ebb6e3f94488@linux.alibaba.com> Date: Mon, 28 Oct 2024 10:28:07 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree To: Joanne Koong Cc: Miklos Szeredi , Shakeel Butt , linux-fsdevel@vger.kernel.org, josef@toxicpanda.com, bernd.schubert@fastmail.fm, hannes@cmpxchg.org, linux-mm@kvack.org, kernel-team@meta.com References: <20241014182228.1941246-1-joannelkoong@gmail.com> <3e4ff496-f2ed-42ef-9f1a-405f32aa1c8c@linux.alibaba.com> Content-Language: en-US From: Jingbo Xu In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6D51412000E X-Stat-Signature: qgsxhm59yjrushuwzwdcyg1tbpgjpasb X-Rspam-User: X-HE-Tag: 1730082471-241944 X-HE-Meta: U2FsdGVkX1/MnHIIUvHIDDdaAt1AO7JNlsatiJKrDlqCTDJPdpUX2PYs2/iWkLl9GLnuhUU+CQ0V+ZLK/Cg7Kybe+vP2IUArI5t/SqeFtS7BzjSRIUHTNISPXHUQQSUGS1V01S5vS+ptyHYUwmzkU2DSOV2WAHaORe1jxNZDAEkG2Y2xclakUfEjV3Ik2kW7JAMP2v6kUcli1+nLQ58J5xVLB8a9Z0sLyMGGFfGE7YPLXMDEP8qEMyitWK1joSLa1bfYIK/gJDE3WYK3ppT1yLW0G0/GxCIZxjJZIW9HG55jmwt7V3YjUorTiCfVt5ttaj6yPORYNmcRaZRFbBSRRqyiw8CI9Al2pdSPqU9M+U8y/mX3nH31C+FwIl9eVkrRpBuXAWLl5ynhKYvXNx1iDFzfjBvpnwbX09pHCRa5BRDtAutoF5Dr9kDOuyZEwjf88VxCQ5Ppx3QgJFbVTzVZRNirUgdjf7BcsYigJEk4Xr0Uhu5XmlT6OwEoCC5GfKFs+jKZooksMrTC3Xa9gkzc5UFPi6sSARaBYv3LTBGO20BzZMb7cMYu3hAiY42k177P2DYUSGDNOssp/Sag/R3KuguF5C7d0y7y4gmWPtvOPuyceRTMcea2cj6K0eAX1LFo9tEgN4nMQLfECVE1rs1ZRm9N2/bZpIevWHvIqHCaNQnKwjJYmuXrPHIlhR6EEi5vipca8hFo0se8VbBzEUMIF6oXXeLUdcIdZ67W/Zno0qC1YGcoTSG1/AL9d1WFLYnXMKl6FUcn0bHTuyn6AY5cf5sJCe7aWIFKq6f2xWMnbPSGzDGXCiTvYf0IEZBJM4sWbtp7hclOADhs6rwpz+3dQObKnlaCZSRyW9yz6it6lDZ6V3O1OX9EoCejtJG4pVkBoHO4h3bUbdkIl/f4lTUxN6XNrJd5zmaAlePeHrhp2Ses4hjHoOgCdsHRmOMh/jayj9VCJlZ7V3R/OI+b4XW sKE4/8ej VXXdemI8LkALaeThDBT8VDJxZo57Juehd+roNmxDmwzgYHd0yEMUURm2Hc5kyQ9oNs0uUof67b933LKngYGZJS6h8QGFx5BX3Mw31tpYlqhE2MlfTtk9IcD7zLRVOEyqm9YW0AbDtOCGoQHwutfSCs1EtHrokocJuMNO6mNVAyo3Ip5edpYrovoaL3l1MvLWJxRjxmoxjWfF0xoi4+c4lyiwQxi9M/pM8xPj2clRKLS8b7TCzEmx4JX1LQBvYJaz+b8I80yRcvlN+9OSU70MbmikrT4ogYpFUCZpAiaDvABcNHJNLSKArdWKn0dXXcNT00C4T/c7B61NBBsxlzY/A3YysE9lKvJz9fD1/skPp9uJbtnRPmiPH2tV3ZwF0y15fFh7yMaDs9Mv8xfVEiJMg9IhrSg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 10/26/24 2:47 AM, Joanne Koong wrote: > On Fri, Oct 25, 2024 at 10:36 AM Joanne Koong wrote: >> >> On Thu, Oct 24, 2024 at 6:38 PM Jingbo Xu wrote: >>> >>> >>> >>> On 10/25/24 12:54 AM, Joanne Koong wrote: >>>> On Mon, Oct 21, 2024 at 2:05 PM Joanne Koong wrote: >>>>> >>>>> On Mon, Oct 21, 2024 at 3:15 AM Miklos Szeredi wrote: >>>>>> >>>>>> On Fri, 18 Oct 2024 at 07:31, Shakeel Butt wrote: >>>>>> >>>>>>> I feel like this is too much restrictive and I am still not sure why >>>>>>> blocking on fuse folios served by non-privileges fuse server is worse >>>>>>> than blocking on folios served from the network. >>>>>> >>>>>> Might be. But historically fuse had this behavior and I'd be very >>>>>> reluctant to change that unconditionally. >>>>>> >>>>>> With a systemwide maximal timeout for fuse requests it might make >>>>>> sense to allow sync(2), etc. to wait for fuse writeback. >>>>>> >>>>>> Without a timeout allowing fuse servers to block sync(2) indefinitely >>>>>> seems rather risky. >>>>> >>>>> Could we skip waiting on writeback in sync(2) if it's a fuse folio? >>>>> That seems in line with the sync(2) documentation Jingbo referenced >>>>> earlier where it states "The writing, although scheduled, is not >>>>> necessarily complete upon return from sync()." >>>>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/sync.html >>>>> >>>> >>>> So I think the answer to this is "no" for Linux. What the Linux man >>>> page for sync(2) says: >>>> >>>> "According to the standard specification (e.g., POSIX.1-2001), sync() >>>> schedules the writes, but may return before the actual writing is >>>> done. However Linux waits for I/O completions, and thus sync() or >>>> syncfs() provide the same guarantees as fsync() called on every file >>>> in the system or filesystem respectively." [1] >>> >>> Actually as for FUSE, IIUC the writeback is not guaranteed to be >>> completed when sync(2) returns since the temp page mechanism. When >>> sync(2) returns, PG_writeback is indeed cleared for all original pages >>> (in the address_space), while the real writeback work (initiated from >>> temp page) may be still in progress. >>> >> >> That's a great point. It seems like we can just skip waiting on >> writeback to finish for fuse folios in sync(2) altogether then. I'll >> look into what's the best way to do this. > > I think the most straightforward way to do this for sync(2) is to add > the mapping check inside sync_bdevs(). With something like: > > diff --git a/block/bdev.c b/block/bdev.c > index 738e3c8457e7..bcb2b6d3db94 100644 > --- a/block/bdev.c > +++ b/block/bdev.c > @@ -1247,7 +1247,7 @@ void sync_bdevs(bool wait) > mutex_lock(&bdev->bd_disk->open_mutex); > if (!atomic_read(&bdev->bd_openers)) { > ; /* skip */ > - } else if (wait) { > + } else if (wait && > !mapping_no_writeback_wait(inode->i_mapping)) { > /* > * We keep the error status of individual mapping so > * that applications can catch the writeback error using > > I'm afraid we are waiting in wait_sb_inodes (ksys_sync -> sync_inodes_sb -> wait_sb_inodes) rather than sync_bdevs. sync_bdevs() is used to writeback and sync the metadata residing on the block device directly such as the superblock. It is sync_inodes_one_sb() that actually writeback inodes. -- Thanks, Jingbo