Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1342562pxb; Thu, 7 Oct 2021 06:02:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxHrzQy0G8OhvB1/jTPHFzqH7zsKJo5m2oOCuM1rm7008J9qBrvaiwRcDFGUEgyzHSLFGkP X-Received: by 2002:a50:d50c:: with SMTP id u12mr6216268edi.118.1633611723659; Thu, 07 Oct 2021 06:02:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633611723; cv=none; d=google.com; s=arc-20160816; b=fg8ej1N0lOhZlVPZFSLmriRglPW32GAjOPvFXwqseFZNtsYCcUYf/YcDKNuQNvRmfB kZqO9RchLZ1PeVoYTiRqvh+PrOvZOMhwWEQTTiAB2ffYmyGQRKx3MeIXN/OQAYKtVgh+ B/H6wCU7khfSToj4t0mVBqsgaGzsiZUGsnxMiwtsOOzbm6DdISYEYhYC1jcgs2J/8yt+ Vu95u5XLYDDnXFXqXG1AOvwfSgGmLxudprB6pW00YRRrsz/121FgOjp7QjSDbhfw2af+ 7nPHNqBUb4HUpKxdcQkAi3VOGKTZOzwW3uaY+wgDYgvGRlC0Qkgatt2v8zteFhCbCmgj 9uXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=JlKsfdmgfXs09taACmDyRZJY8EiHSnNfp8iCZ5IXTlY=; b=HkweRkESWi/Ey7tyrsFUdq6AtOwQS0BniuEE01W1fusHuP4Mmdqzvo7oUj8DGCycwr g9RT6fcgelhlpEj2GL1hDJoXBB5IZtD/3jOP5heARKHB6j+UYuaPoXhAqwMerTYm81Gh oCpboT01+sXXqJuGstEvCwGiQQgoxFRBuUMVkGCVaUMb0ORVP/a5VxH5GTyXqOh/5qaI /Rk5OSL1KuhypYPX0ST+lpis5Zljs9uBGpEx+NUc1wlwUc+sT6mlBVV5HZefdhSQuULS QlL0365m2XSfbgRRWGQFplxXk13pc5nPzXxm0FSD3mbEC4iOawtrR4Ykjl/5wE7jbUgL Bchg== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=Pq29b+EC; 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 o6si32543010edi.516.2021.10.07.06.01.32; Thu, 07 Oct 2021 06:02:03 -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; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=Pq29b+EC; 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 S241197AbhJGM33 (ORCPT + 99 others); Thu, 7 Oct 2021 08:29:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55462 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241288AbhJGM32 (ORCPT ); Thu, 7 Oct 2021 08:29:28 -0400 Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 91A96C061755 for ; Thu, 7 Oct 2021 05:27:34 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id o124so6564372vsc.6 for ; Thu, 07 Oct 2021 05:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JlKsfdmgfXs09taACmDyRZJY8EiHSnNfp8iCZ5IXTlY=; b=Pq29b+ECnINLhLjebcICFPMl5kZefTp91ONzUQAF3MiFKcnUY/fr26wFSGnUQLNPtw krwpnbduhJfqVIxHXtSreaczjcWiqGEkqBbnV1X8j3IlqHRu4TYSHvWaMnsHzFfS7B/y B//L+TWkij04JKEW5cQ3aktGXvFOebgmq9wTQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JlKsfdmgfXs09taACmDyRZJY8EiHSnNfp8iCZ5IXTlY=; b=pn55+gCJEKWKZ8YAx7iKmbz3exUbmQoJHc7Vv3hohbWvNi4KFghQZJs/qlKft/rCrA Peash3bLSP4T5GsovjRVG6DNCwnSmK/Qp78F6bHXjKEIQ9uweSNc6OwukJ55VTU0RIEg pUuW0wyWFuNgXSvD3YFOqsIT2Bw8fde5ggs45P5H7Ec1z09OZyc9h9DvxxpbG6BSEAP7 pLB/kf3KEL1jlg7/mAlMnUSNMYQfQ7KksJ0KGeQhryxir2QcDq0XyeJQh/gpZ6gFvl69 ajwMtKRNHKaKYbzkUyBTIRdBA/2AEDXElFhdcj6HMPwtkvrm5V9v1vsnJuy9Lt78Wt2U 5b5g== X-Gm-Message-State: AOAM533vGFhKVtml9ATW9yKuLesgm2XFa8QqHiRx0Xfb1GEiiVNRd+Ym RsaeQbcZCpt/xKxTDrZZocLG9dP10uIdm5JSaKvOkQ== X-Received: by 2002:a05:6102:3c3:: with SMTP id n3mr3706923vsq.19.1633609653793; Thu, 07 Oct 2021 05:27:33 -0700 (PDT) MIME-Version: 1.0 References: <20210923130814.140814-1-cgxu519@mykernel.net> <20210923130814.140814-8-cgxu519@mykernel.net> <3b660f79-9f60-5acd-0b9a-47f9e3e6a04b@139.com> In-Reply-To: <3b660f79-9f60-5acd-0b9a-47f9e3e6a04b@139.com> From: Miklos Szeredi Date: Thu, 7 Oct 2021 14:27:23 +0200 Message-ID: Subject: Re: [RFC PATCH v5 07/10] ovl: cache dirty overlayfs' inode To: Chengguang Xu Cc: Chengguang Xu , Jan Kara , Amir Goldstein , linux-fsdevel@vger.kernel.org, overlayfs , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 7 Oct 2021 at 14:04, Chengguang Xu wrote: > > =E5=9C=A8 2021/10/7 19:09, Miklos Szeredi =E5=86=99=E9=81=93: > > On Thu, 23 Sept 2021 at 15:08, Chengguang Xu wro= te: > >> 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 wi= ll > >> + * 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 =3D ovl_inode_upper(inode); > >> + > >> + if (!upper || !(inode->i_state & I_DIRTY_ALL)) > > Could we check upper dirtyness here? That would give a more precise res= ult. > > 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. That's fine, since there are no more mmaps at this point. > > > > 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. Same reasoning here: after upper inode is written out, the dirtyness in the overlay inode doesn't matter since there cannot be any active mmaps. Thanks, Miklos