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 X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 D3D9DC433B4 for ; Tue, 13 Apr 2021 02:14:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AEB2261370 for ; Tue, 13 Apr 2021 02:14:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240540AbhDMCOj (ORCPT ); Mon, 12 Apr 2021 22:14:39 -0400 Received: from sender2-pp-o92.zoho.com.cn ([163.53.93.251]:25304 "EHLO sender2-pp-o92.zoho.com.cn" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239254AbhDMCOj (ORCPT ); Mon, 12 Apr 2021 22:14:39 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1618280047; cv=none; d=zoho.com.cn; s=zohoarc; b=T4MaCSudNEtndU8u98W1zkmY6SPQiGwHtzV8gpCUO7oEgwrOn41LAAASvnQoorPJjO405H5G2Eezi3cen3+KF5Tb5XsUE5sVVeyWLKmk+4vM+8Ht1OlbyCb/HnbB7ETegB3IYPk+VbkiSPRgkavdrmatfpkZk4HNkUgYZprBnlI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com.cn; s=zohoarc; t=1618280047; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:Reply-To:References:Subject:To; bh=QfEE3GeQ2y8jkajBXmU9OhellyZGKOuAfHuTC8ZUNd0=; b=Sjn+x9kM3fJ82C9V+1dA/t2ZOc4q7yP23ApoZbMmjFDMZxdSnBPhhRXRqFYka3RevplTEcselluOmNxx682MvSS8bg9xeWM9R8n1f+GJSlIoUQTmIx+HIPkoTxB10dFA+Cxm0BgCBfyOJ/m/3K5n6kJp7xm4Dtp3xS6fl6JukoA= ARC-Authentication-Results: i=1; mx.zoho.com.cn; dkim=pass header.i=mykernel.net; spf=pass smtp.mailfrom=cgxu519@mykernel.net; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1618280047; s=zohomail; d=mykernel.net; i=cgxu519@mykernel.net; h=Date:From:Reply-To:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=QfEE3GeQ2y8jkajBXmU9OhellyZGKOuAfHuTC8ZUNd0=; b=ZMPIyw3rYvRGao8v9OmNpnTWrgjoWmfDyDcP8j7IfUVodwZKhRK1juAzNaEMLtPN 3blKsudY632CfWZQVtsy/mHKP2ZcD0eWzUyq5PhoPmDJTgbEuv9m+Zg/Vn6OzrvvYeI TYKTzZk+tTsNj3aVYsrA78djZV5PoLCI7saeEvnI= Received: from mail.baihui.com by mx.zoho.com.cn with SMTP id 1618280044464418.17248206147053; Tue, 13 Apr 2021 10:14:04 +0800 (CST) Date: Tue, 13 Apr 2021 10:14:04 +0800 From: Chengguang Xu Reply-To: cgxu519@mykernel.net To: "Miklos Szeredi" Cc: "Jan Kara" , "Amir Goldstein" , "overlayfs" , "linux-fsdevel" Message-ID: <178c901d7ad.fdc7d65c21509.6849935952336944935@mykernel.net> In-Reply-To: References: <20201113065555.147276-1-cgxu519@mykernel.net> <20201113065555.147276-8-cgxu519@mykernel.net> Subject: Re: [RFC PATCH v4 7/9] ovl: cache dirty overlayfs' inode MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Importance: Medium User-Agent: ZohoCN Mail X-Mailer: ZohoCN Mail Precedence: bulk List-ID: X-Mailing-List: linux-unionfs@vger.kernel.org ---- =E5=9C=A8 =E6=98=9F=E6=9C=9F=E4=BA=94, 2021-04-09 21:50:35 Miklos Sze= redi =E6=92=B0=E5=86=99 ---- > On Fri, Nov 13, 2020 at 7:57 AM Chengguang Xu wro= te: > > > > Now drop overlayfs' inode will sync dirty data, > > so we change to only drop clean inode. >=20 > I don't understand what happens here. Please add more explanation. In iput_final(), clean overlayfs inode will directly drop as the same as be= fore, dirty overlayfs inode will keep in the cache to wait writeback to sync dirt= y data and then add to lru list to wait reclaim. The purpose of doing this is to keep compatible behavior with original one, because without this series, dropping overlayfs inode will not trigger sync= ing underlying dirty inode. Thanks, Chengguang