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 740CBD5B158 for ; Mon, 28 Oct 2024 21:57:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C09B36B00A5; Mon, 28 Oct 2024 17:57:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB8746B00A6; Mon, 28 Oct 2024 17:57:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A81206B00AD; Mon, 28 Oct 2024 17:57:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 896E26B00A5 for ; Mon, 28 Oct 2024 17:57:39 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3EF97AB883 for ; Mon, 28 Oct 2024 21:57:39 +0000 (UTC) X-FDA: 82724372682.10.E110C92 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) by imf15.hostedemail.com (Postfix) with ESMTP id 45ADCA002E for ; Mon, 28 Oct 2024 21:57:13 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=I5OsjUkU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.222.171 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730152614; a=rsa-sha256; cv=none; b=iCuGoh1SQM/eTxwMlnVRGbe5ftOH2JdA5VuALk4CJ2yIlFT57bheVocRcynpaNdmfB9WPQ vsTM4lo7AkozhbBbWG9VY1zi/DsHVeCGW03BPwNb9g1j/2XNIrZSqQ6LRYiJ80Se4+SRTz OTKy/NGk0KSUH8bv1tsqKuGVZFaSH5g= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=I5OsjUkU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of joannelkoong@gmail.com designates 209.85.222.171 as permitted sender) smtp.mailfrom=joannelkoong@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730152614; 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=LoDhG7CtWuow17GcDNM6QpBq1OhuaDs8XrsewrMi9/A=; b=J0EtaRCrctnKqz2fNR/jl79/XS1lL3teOCm9B1YkI0Mjl0Qja56lbIJOaXDfdr/UZKJOTc HoETvsfdNHyvZmqVO+dBL6bd69FX4qdB5GbzGCdCY19v+pvGIfFY19VgEPYbyAtNjY0Ig6 p6tvlRWgZM0yscBdoAZ2wsQTuhlkNh0= Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-7b1434b00a2so387896285a.0 for ; Mon, 28 Oct 2024 14:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730152656; x=1730757456; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=LoDhG7CtWuow17GcDNM6QpBq1OhuaDs8XrsewrMi9/A=; b=I5OsjUkUKDW3mQ7dLh2ONZ/zqNUVLwWnBB4/H3dmfabhIxHma6VkRFT2iLF3qIqZOz 1zbenmokdNzdkt62tMqO1RRltdoHUaPMm9jvN/ngeWfqZSdI3C/IoQvaeNuvyr/s/+yM pcmGMt5iPZYVaFoJqe6JArg9eMniotgpPG7sHKOq0Z5ogxn+YlHsZRh0Mna5gBWM+/MC WGUwiDvhM32dTSHrEbdYdPzBe+6w4Y6oAKm7q0lxVqDtFCIl3Vhdy7y7yrvvTsXF8l9A B7Sk71KvT+CSt4iIKUFgLKIV+55lrIvgovkRMwsctfNGnfEcea5cR4nmcDcGqUtgPGla BsdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730152656; x=1730757456; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LoDhG7CtWuow17GcDNM6QpBq1OhuaDs8XrsewrMi9/A=; b=rnVWwPcN5JiIY2Wj/SMq7pMvOtONI1us4BkAUXJAlNXzRpeuLmcDxAYAMVknlZb+lE HVoecV6J4LORXr2zAeZzyxafEnS2nZSRlb5kF7CbbPWrLgOERyTokPZygEcRpkvI6L8X U/Qd8Zjnm1slknoQpZwCd9/MMizzh4j0d/iP3Iw0TNj92pA5I5Uu8PefVmDv+Qx3r+9B 8JZ0Z7R7YziN5dBJWRq/FGMM9hIdBZKsGJSNQudyXT52kBFLeitPp5eX4rlwS88oA6TD 9vtJSkSrYhEPhqKO2BW4dsxLsVPZ6FSjJXS90m6EgVHckw6ogWPeUPJjTs7rk3AMrnxC AHfw== X-Forwarded-Encrypted: i=1; AJvYcCW9SgqY1hVcddf5f0F+ZJKbzhN/45Xl2mMatdLF2uxPD3BEU8YrGewg/mlZxqgvwspuWedwR6BmRg==@kvack.org X-Gm-Message-State: AOJu0YwsnnJppuffECaqio7i/8pht2n+zOYcniByML62hihD/pgIxiRe P+D0AXbeCOdMs5uKpaoJ5zl0o8Hi/r1QPw48ZQiZzEGFwvxaU4JBas5nJeCzmBqmj+cTZ0pjL+S Wu8OR/H847Ah081YUwRTWzWTkS9Q= X-Google-Smtp-Source: AGHT+IEFe/Uk5OKqArsQm2g0vdVuamajpL31KZbxy1aFKSSH/tVAHs6md0SIuT+HkltJCmJO9+vRCPsU1qhDzYn4UmM= X-Received: by 2002:a05:622a:28f:b0:461:4a7d:202f with SMTP id d75a77b69052e-4614a7d3be1mr95798991cf.19.1730152656524; Mon, 28 Oct 2024 14:57:36 -0700 (PDT) MIME-Version: 1.0 References: <20241014182228.1941246-1-joannelkoong@gmail.com> <3e4ff496-f2ed-42ef-9f1a-405f32aa1c8c@linux.alibaba.com> <5825a89f-7994-4de5-aecb-ebb6e3f94488@linux.alibaba.com> In-Reply-To: <5825a89f-7994-4de5-aecb-ebb6e3f94488@linux.alibaba.com> From: Joanne Koong Date: Mon, 28 Oct 2024 14:57:25 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] fuse: remove tmp folio for writebacks and internal rb tree To: Jingbo Xu 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: g7eh14hyph9t7zh3bddz7sibej5inomj X-Rspamd-Queue-Id: 45ADCA002E X-Rspamd-Server: rspam02 X-HE-Tag: 1730152633-202049 X-HE-Meta: U2FsdGVkX18i9BsV9YgmvHoyJ7FPqZH2VveeO3OYm3a51o1SsPKeKRqdJxqgB9jjzSPo5EMPqKegyyAeDkNDw9l8wrFGrP8WR+QzfVDCXd5TDO5c9MOwWQxfdsaRuKHaGLfZ0T0KmxuOqh/btrQX5aTHEJ0onCvf7R1SjUSphrPBQRj0pU4l5NDnrkqj4fq6JLYMPHkBiObDN5xCKWg8ZDPCyLQLknisvzddfepjD9Trhn9387GAGN6Ytp/CFUcVqLKkXqr+s7BxUy4DlztNmmXOEW8pIefOlYdYY/1btxLKEOK9qzFuZCGffGEk0MJ47bKyFBcCiYmYNeicpR70ErLD5BpGGJ3K0edhHHA5s7/CGebwbKblFwiRzppz/i0T3LB30NqLWkgVx0qHhQKUXMP/AMRebKsgHXBjqd7iULnKCS2eTlgBh49F7Ph01r4VMnpcsgkv3LHNUpiFJVwhaji+f06M94/O+mFsYsWjQ51rVdGiWHRRTiY4VsWtiNKbXCHDvCfqWrICm0wFiokUw30+eGMjk/b/5EE488GTeOUaJZSTOc5R73d5Jja1zxWnqefnxDDECKerPtzevbjhBmj9oWiJnj9Pciki4UiO+T5KOnIrhi0qnM7B4heUGExzjsrJRhJeeZ8oByHPTmEReVha+h6Gi+S1yflSWAPMvixSbDyWY8QpJj8W0oikbgOVFoBVfFVcmXZPDF6O/r0/1ie0cOsMqWEWqbhyW/PIb2SJ9Pw6JziR0I7dVYrFsUq7e7I0Ovs7ici7Jtkq0b1dOnfLjZCXkZqh4rWwTSKq1aZlaaVMREBhuoyeqHNzlYZOYC1Fq4UIgsrOrg7kvUZqrQETqw4v7jh4Fd+IDlXoskwwVL0wtI2e3vupTZbqEznc/N0EGyvc61p40Hcy9/nb9uj3gvJoVXG4N2CyfgFJGyuW4USgvZ/6EKmYjhJnkPPFHaKZpdrFoeBi5yZ4LSY nRlM2Qzm W9fySYa+z2Eaq+SUY6Jvg4D6c4y5jMTt3vZSaCahdIQB10B2vqZJKpwx0JVZicD7p0zl1nrg8UWpTm250GS77UlsJ0JCRS5fDkgOv+DNbBLGkKcSenIenjEAdzKr4gEGPnpwac/Gk7S5PZXxpnTxGcX1XaDfNddAoZ+fKfi5D64Z9HOO3avhs4hzbIL+uBWvCDwgdNECF2rfBPi85jNWKx+9FUCR8y3AaFW/qLTuydrUgdvxdx0Cjha/i3phOyKQLJKucDk2by+pkNfPAu8m+MyPx59dvlJ5RAMA0wBeo662RPheqWOJWfNdDH3kNVLWpPVaMbM2FDVjFXd6d9uK+AVT9tmKJ9xUnk1+k+V0Uz3iizfpCjo5zMCEvmuxYC+VHjl1wOqd14Vyl0woq97vjnXYM6rMRpfzX32z6njGCHs394F6H/qDSFne7Ypm5B3+83jzIgpd01bbe0Us= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 Sun, Oct 27, 2024 at 7:28=E2=80=AFPM Jingbo Xu wrote: > > > > On 10/26/24 2:47 AM, Joanne Koong wrote: > > On Fri, Oct 25, 2024 at 10:36=E2=80=AFAM Joanne Koong wrote: > >> > >> On Thu, Oct 24, 2024 at 6:38=E2=80=AFPM Jingbo Xu wrote: > >>> > >>> > >>> > >>> On 10/25/24 12:54 AM, Joanne Koong wrote: > >>>> On Mon, Oct 21, 2024 at 2:05=E2=80=AFPM Joanne Koong wrote: > >>>>> > >>>>> On Mon, Oct 21, 2024 at 3:15=E2=80=AFAM 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 w= orse > >>>>>>> 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) indefinit= ely > >>>>>> 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.htm= l > >>>>> > >>>> > >>>> 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 page= s > >>> (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 mappi= ng so > > * that applications can catch the writeback er= ror 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. > Great point, thanks for the info! > > -- > Thanks, > Jingbo