Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1304757pxb; Thu, 7 Oct 2021 05:16:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyWPe6S4qgwKIz6NJvmQFFR+D7TSLh1EBEwDzQCTb+MlBp3S7hlhU77hymyQiQtFF2tfuNs X-Received: by 2002:a5d:4a4a:: with SMTP id v10mr4970178wrs.306.1633608968146; Thu, 07 Oct 2021 05:16:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633608968; cv=none; d=google.com; s=arc-20160816; b=YbgY7o6LPA4cCSS6qaL/IhkTUkVMTexsrN+GzxU6mmeYlrKJ47Es7w2IWUyxMpfonv U9hF4QncRe4Cwxh6sU9gYXQTUobAGs+aCbPIOrfnmyjTAdcCAyhnRkpY5hLnWMXwmKJo OOHk+wDUAdi2qooxKFUYiMdQHiZwP5Xo6S7jur5TvbcNb0D5xvgwdo9spMozosgy+t81 h7X1uyo5faRKMoGzU46hebHHX2VfTKNzohtxbF0PCoPSJnnwJUE9S3rcwAOcia5TSL8M 9o5PFMf+edvG5MqBBgEv1iK+uaGw8M8grbTcl8c5I8vy2nVPvSE6AkQ2WlALXi/k+uzt RFOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id; bh=67ek647koGPU23VzwZjd15WmfbxsZqM3mgb6Xp2EtAE=; b=EPnghYu331FXOz/29RE+ovg4ELsGd1CMdeHcc+SulcOQE/pL9R87WjhseV5Op7JwFp gMxBtSfYlrTdFKSgDJcnqmtI4iZtdK3T3800yitJm0sY8x+EMDDzrmajH6UquFCqQ4Sy hVXBCTlhdrfjSEex9VLOpFtyqGXv09hqD+PgYECmPzYg/T+7gouithkofleRFyiL1fpf 7cZI//bZganf61CPtUzG8S/AmBI2FBkvRPHOMAJ0JOK7bqtzqopmPH4V5XCeqow+mH1k P97mKXy0YbhHaOpBM1UzBBYZRGtL2kzprw2tQ124k2eMPHFVcdnETHtPyJXIYUGu/Rad 1LHw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 8si10332586ejd.768.2021.10.07.05.15.43; Thu, 07 Oct 2021 05:16:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241215AbhJGMP4 (ORCPT + 99 others); Thu, 7 Oct 2021 08:15:56 -0400 Received: from n169-113.mail.139.com ([120.232.169.113]:43535 "EHLO n169-113.mail.139.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241206AbhJGMPy (ORCPT ); Thu, 7 Oct 2021 08:15:54 -0400 X-Greylist: delayed 560 seconds by postgrey-1.27 at vger.kernel.org; Thu, 07 Oct 2021 08:15:52 EDT X-RM-TagInfo: emlType=0 X-RM-SPAM: X-RM-SPAM-FLAG: 00000000 Received: from [192.168.255.10] (unknown[116.30.194.209]) by rmsmtp-lg-appmail-31-12045 (RichMail) with SMTP id 2f0d615ee24f94a-8b09a; Thu, 07 Oct 2021 20:04:31 +0800 (CST) X-RM-TRANSID: 2f0d615ee24f94a-8b09a Message-ID: <3b660f79-9f60-5acd-0b9a-47f9e3e6a04b@139.com> Date: Thu, 7 Oct 2021 20:04:30 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Subject: Re: [RFC PATCH v5 07/10] ovl: cache dirty overlayfs' inode To: Miklos Szeredi , Chengguang Xu Cc: Jan Kara , Amir Goldstein , linux-fsdevel@vger.kernel.org, overlayfs , linux-kernel@vger.kernel.org References: <20210923130814.140814-1-cgxu519@mykernel.net> <20210923130814.140814-8-cgxu519@mykernel.net> From: Chengguang Xu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2021/10/7 19:09, Miklos Szeredi 写道: > On Thu, 23 Sept 2021 at 15:08, Chengguang Xu wrote: >> Now drop overlayfs' inode will sync dirty data, >> so we change to only drop clean inode. >> >> The purpose of doing this is to keep compatible >> behavior with before because without this change >> dropping overlayfs inode will not trigger syncing >> of underlying dirty inode. >> >> Signed-off-by: Chengguang Xu >> --- >> fs/overlayfs/super.c | 16 +++++++++++++++- >> 1 file changed, 15 insertions(+), 1 deletion(-) >> >> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c >> index cddae3ca2fa5..bf4000eb9be8 100644 >> --- a/fs/overlayfs/super.c >> +++ b/fs/overlayfs/super.c >> @@ -441,11 +441,25 @@ static int ovl_write_inode(struct inode *inode, >> return ret; >> } >> >> +/* >> + * In iput_final(), clean inode will drop directly and dirty inode will >> + * keep in the cache until write back to sync dirty data then add to lru >> + * list to wait reclaim. >> + */ >> +static int ovl_drop_inode(struct inode *inode) >> +{ >> + struct inode *upper = ovl_inode_upper(inode); >> + >> + if (!upper || !(inode->i_state & I_DIRTY_ALL)) > Could we check upper dirtyness here? That would give a more precise result. We keep tracking mmapped-file(shared mode) by explicitely marking overlay inode dirty, so if we drop overlay inode by checking upper dirtyness, we may lose control on those mmapped upper inodes. > > Alternatively don't set .drop_inode (i.e. use generic_drop_inode()) > and set I_DONTCACHE on overlay inodes. That would cause the upper > inode to be always written back before eviction. > > The latter would result in simpler logic, and I think performance-wise > it wouldn't matter. But I may be missing something. I think we may seperate mmapped-file(shared) inode and other inode by clear/set I_DONTCACHE flag on overlay inode if you prefer this approach. Thanks, Chengguang