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 39693C8302F for ; Tue, 1 Jul 2025 05:41:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C97066B0098; Tue, 1 Jul 2025 01:41:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C47B66B0099; Tue, 1 Jul 2025 01:41:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B84326B009A; Tue, 1 Jul 2025 01:41:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A2C116B0098 for ; Tue, 1 Jul 2025 01:41:05 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 56D14C02D7 for ; Tue, 1 Jul 2025 05:41:05 +0000 (UTC) X-FDA: 83614597290.16.21B7672 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf26.hostedemail.com (Postfix) with ESMTP id 82A1E140003 for ; Tue, 1 Jul 2025 05:41:03 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=BGs+whJA; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of djwong@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=djwong@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751348463; 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=s4paknHHdzprs/ut23i6dVQKxAKCPYS2SC+0GkpiGXc=; b=caow23NQgb+YboB5sb35bhpWGd9W2597MTPcCLvYBYb9aftuSMNFfDKkG/NFlnKIT7vyG9 KLoNxz/TvnwXuvDFZVE9+Dm8ci5ASTp2rtpsQnFaBRpKWOmy2ABNq1D+vTqfJDOxeNGr1e HkGazqLVUEzW623LJQmJCWDne8kqkxU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751348463; a=rsa-sha256; cv=none; b=bhPolHzy/1P98hHIIsr8IWRQ+sisT1jQv2I2EXlRKf0mS6kEZDbaV8MvSD/6+CcH2lGx+/ T5V19BkCy4dZnskAyQj+8Bpnyrk+QiE5SE595vEnfunhO+B6UX6rcTcgu1kXn/MSzcuytF fnZQP6eII+MskER5KgQa4z+Plyq0o8U= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=BGs+whJA; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of djwong@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=djwong@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 3A85B43FF8; Tue, 1 Jul 2025 05:41:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0E2F0C4CEEB; Tue, 1 Jul 2025 05:41:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751348462; bh=UDsiqeD9Rx7beaI8/Y2+5mhKK/YEz8suJYDVh5wpleg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BGs+whJAJv9u3TGXfbF3ek+G4CspgAar85NzNF2hzg13LSB7qr7Sx1ZRyGI8Bd+bV KpYbTkVKW0RgugdZR7ALw7ATVVx2kgHv7uyWTbF1LzGkrBW2dyDkiq1qp9YkVO6In3 9riQBRXi88FCK/DsBxzbBIBWPs7HqzYXT+MldcJvby7tnR7wM2yxqBwtQ/03bKNCxN TTcwx4YO9j1MG7PW16XM96od+XZ/jCwSbIgy0LgkvZGm7X7Bmt3LZSINsls5+VWoz5 NQgLfd2rurC+Uk1letQK5rZP6CAhBaSbBV3mFHkE5pOdU3NBj2x+GNYXKl6DVa1ueF adjgbStbzlLGQ== Date: Mon, 30 Jun 2025 22:41:01 -0700 From: "Darrick J. Wong" To: Joanne Koong Cc: Christoph Hellwig , Matthew Wilcox , Jeff Layton , miklos@szeredi.hu, brauner@kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, bernd.schubert@fastmail.fm, kernel-team@meta.com, linux-mm@kvack.org, linux-nfs@vger.kernel.org, linux-btrfs@vger.kernel.org Subject: Re: [PATCH v1 5/8] iomap: add iomap_writeback_dirty_folio() Message-ID: <20250701054101.GE10035@frogsfrogsfrogs> References: <20250606233803.1421259-6-joannelkoong@gmail.com> <20250609171444.GL6156@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: aqheaaknw7387u9ufn1cnotqt7z6p4rn X-Rspamd-Queue-Id: 82A1E140003 X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1751348463-647521 X-HE-Meta: U2FsdGVkX1/+BTDqE/xIqaD2Zum8oKtFrYAd0RKHXm2avMdxZq3BZKkEZhslxp8xwGK93RxliyT7eNbdvfRvZWwEv6RvZSP8uTzh13imo6N/+7u8j2fuZWN/vLos2YzoVfc2CmmQr4wbt5fgiA4l5VtKc8EUPyWPn3LBXQjoxY4Fg9ykM4SdgydBSM2dR8N9uyW4lKkQoKOByBU8b69wjHPxTL/ltMiuplCUdPqE+UitD5osG9vlIHWBPachwAb9fkblpmEWSQ/sgRdB2a4f/7Tap8OEpJMQTC3KqEFpY+8HnDZdb69Wr6cAkvDsvFKIO/ZoDRJlQIOKvDo7pO7ZFwHQGp/t0UOzuJ26cgYfMtmzydPgGQi+XFsaluzJ2mYU1Urm8IQgNZTQcIT0uWVtknCd3ViAK02SVdsePdkHHKZaV2+jzdzkPpXx6uMixZV0BOrW2f2ZU+mbrwz/HyS2t1fT33Yxvnkud66K92u5a2mvSrTDibOP4WZanVJnnlF+BnMyOwm3eBpCMp+mm+0mPxA9vWLRIoJooymL8ouS00BFEv4jlhLIdPDh2PnGJHmMrJo/+V2aNczqMSxHG5jUTQyofG36TcVVRRqAjo6atkEZQyHLQZ5SAbzf+3up95drJUyzKTBosA4h5HqN1JBafaxDqh37PpZfgPtdwqi0G5zhFry/eqXiAnUTQRuB4mux2hx/OMoibc9fnZrmnO8Xs+wj4y4NcU4TqMMHA/30iuQzu28FDSWX6UHdPCSawbvwb6oVT0WTkvWUT/B3bpt6TkPoCSRTHwZsKSfNxO7cAFwFFGDvL/yu63ZEJXBY7+tPruOLFqZUkODruAYDmmm9TZazkqQwD0Qs9K2w23L1PkAk0ml3L7zm0BD8MtaCHDxK16P8HO4FLZs1J8OnHUqw5tbk8ClgR+vPx+4lubSwwGmm6ojI6rHbJSABaO1+U+L0H4OYrlt2mJ/IP+W6S7Y iRG3OPC8 7eUdHdupidphmK9KlwkQLH7XGJa33MCR0JqAJziQvndDauqZYbraU4AMBw4JrbZo+XJXD/zPPbT/WkTx70aHVEU55WCGeUJtrrPFWrj89Qb6dmHq+rAStqJJAkjhO4hQir0hvIf2ie2FRoVaK3czVFjwYZxdVXreX62/++XXwr+LFlAzXImv99A8HQpsHN0A3HYXJRV/De/kJnDjI9ilEwK6YF7uKwJrY/jnMqba1QM1F+nIX4ZvJgV+jpPar83tdZTMONe9pYIR0WKTFarPNUFFwDadzdXuIp9ikEzqkGMsEPXOjntebXi5VsRtKPQ6nQhUxWlPuNPSzNHwUmK5Wcsfr0nGI+Tih2iqKi5vZ121ehyfYgTOlLqP9z5Hq6lYgK6hehbl/s9uF5ilRt9WbP8boR57PVsgEttfm 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 Wed, Jun 25, 2025 at 09:44:31AM -0700, Joanne Koong wrote: > On Tue, Jun 24, 2025 at 11:26 PM Christoph Hellwig wrote: > > > > On Tue, Jun 24, 2025 at 10:26:01PM -0700, Joanne Koong wrote: > > > > The question is whether this is acceptable for all the filesystem > > > > which implement ->launder_folio today. Because we could just move the > > > > folio_test_dirty() to after the folio_lock() and remove all the testing > > > > of folio dirtiness from individual filesystems. > > > > > > Or could the filesystems that implement ->launder_folio (from what I > > > see, there's only 4: fuse, nfs, btrfs, and orangefs) just move that > > > logic into their .release_folio implementation? I don't see why not. > > > In folio_unmap_invalidate(), we call: > > > > Without even looking into the details from the iomap POV that basically > > doesn't matter. You'd still need the write back a single locked folio > > interface, which adds API surface, and because it only writes a single > > folio at a time is rather inefficient. Not a deal breaker because > > the current version look ok, but it would still be preferable to not > > have an extra magic interface for it. > > > > Yes but as I understand it, the focus right now is on getting rid of > ->launder_folio as an API. The iomap pov imo is a separate issue with > determining whether fuse in particular needs to write back the dirty > page before releasing or should just fail. This might not help for Joanne's case, but so far the lack of a launder_folio in my fuse+iomap prototype hasn't hindered it at all. >From what I can tell it's ok to bounce EBUSY back to dio callers... > btrfs uses ->launder_folio() to free some previously allocated > reservation (added in commit 872617a "btrfs: implement launder_folio > for clearing dirty page reserve") so at the very least, that logic > would need to be moved to .release_folio() (if that suffices? Adding > the btrfs group to cc). It's still vague to me whether > fuse/nfs/orangefs need to write back the dirty page, but it seems fine ...but only because a retry will initiate another writeback so eventually we can make some forward progress. But it helps a lot that fuse+iomap is handing the entire IO stack over to iomap. > to me not to - as I understand it, the worst that can happen (and > please correct me if I'm wrong here, Matthew) from just failing it > with -EBUSY is that the folio lingers longer in the page cache until > it eventually gets written back and cleared out, and that only happens > if the file is mapped and written to in that window between > filemap_write_and_wait_range() and unmap_mapping_folio(). afaics, if > fuse/nfs/orangefs do need to write back the dirty folio instead of > failing w/ -EBUSY, they could just do that logic in .release_folio. What do you do in ->release_folio if writeback fails? Redirty it and return false? --D