Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1492925pxb; Thu, 7 Oct 2021 08:49:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxP6m+LHAqY2i6fnvcaO7WgksDsvCzWYrjHIXVki1XtH1Rztfp4HU/pYHvFTspVPX4gS0Tc X-Received: by 2002:a17:902:f703:b029:12c:982:c9ae with SMTP id h3-20020a170902f703b029012c0982c9aemr4782759plo.20.1633621784870; Thu, 07 Oct 2021 08:49:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633621784; cv=none; d=google.com; s=arc-20160816; b=drVSItPFENRsme7SnJrn2L4AcYXniH82Dwkd45H6e48g2xkzmJw7n3hI8eoVo81EYM MRR7Bw68O0e11W+z/jcrObEAP5UqUTYxdgoPIx06lmyDKLmGYVDeXAsZ0Kq2hNlP5bzf 1qF7rYOyorQ9pr00iw8uOr6ouSzPXgl3/vE2EaHEtL8Z6AxrvPHtCUXYoo9uYjEp82iM 2Bgr6Ov3Nk1QLPXENORUoHiCz4V0MY8GLsDIATTARviVWYFkWNklHJlsrulp5N2xp2qj /pUo3ce+BTgSVYoOAk459pFDbtaM7Jr7lVE1GD7a9DN+bequgKpTa2Zyht4N+1ApQR8q dtFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:dkim-signature; bh=Wg27QjHqYVAaPstpf7so0rTJ0eaThEY9sMKMxSud6sM=; b=0JvhWpwUmQUbk6F8m3xKblAcVHnSIwpAymvGWyD71ADTp+l1RN9R4zNPIzEWE1eqBD 09cTkUnxVJ2T7U4pI0hPUQiOqzf3ZmkincrSht+kNWqdP7CY2bItGNn2f+K/ecsfE5Bn qe7kAso4If0so3wKCsZTrWMCPufCXvw0etg2FQdjmbrVL3zKDmBr/TdgCgR1hSjbhn/2 s577ultISrMG7rCKbe55XOhU2CtZCU+s1bh+HGeblZvJOI92H1mStLu1yk5oBlBWxVdK N5SuoIox13ZFHKLCV6Ex0SmjOW6676Tgm/vUHVg19CmwGnY9NqRJlyKfdvNqfAzLIB7+ ayHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=ZNQracSv; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; 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 pf3si11115809pjb.53.2021.10.07.08.49.31; Thu, 07 Oct 2021 08:49:44 -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=pass header.i=@suse.cz header.s=susede2_rsa header.b=ZNQracSv; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; 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 S242157AbhJGOnw (ORCPT + 99 others); Thu, 7 Oct 2021 10:43:52 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:38230 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242110AbhJGOnv (ORCPT ); Thu, 7 Oct 2021 10:43:51 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id A26E522415; Thu, 7 Oct 2021 14:41:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1633617716; h=from:from:reply-to: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; bh=Wg27QjHqYVAaPstpf7so0rTJ0eaThEY9sMKMxSud6sM=; b=ZNQracSvE5WinILbpjV5/pnPN/WhcsGYEbozg2lYkFmxM8w9LMxyrRLkjz0YkLxLctxJfq Ail7uzAM79IsU/KTJXUQtPiXWN/DOimtNRXCUWg6qz8sWhoIpiaQVNrMZiirTMHSEeif2H EBuLbdN3NiRia3c+RNicp6S3QK6m1rI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1633617716; h=from:from:reply-to: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; bh=Wg27QjHqYVAaPstpf7so0rTJ0eaThEY9sMKMxSud6sM=; b=YD5i1L6NIygVjyo/v1tKRFa66cgqmirpQnXpl9Z6oWH6LwcqCTatziIQJZIZiOSAM4pBvO 8Ej2oPK7pkC4iYCQ== Received: from quack2.suse.cz (unknown [10.100.224.230]) by relay2.suse.de (Postfix) with ESMTP id 59C6FA3B87; Thu, 7 Oct 2021 14:41:56 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 34B7D1F2C96; Thu, 7 Oct 2021 16:41:56 +0200 (CEST) Date: Thu, 7 Oct 2021 16:41:56 +0200 From: Jan Kara To: Chengguang Xu Cc: Jan Kara , miklos , amir73il , linux-fsdevel , linux-unionfs , linux-kernel Subject: Re: [RFC PATCH v5 06/10] ovl: implement overlayfs' ->write_inode operation Message-ID: <20211007144156.GK12712@quack2.suse.cz> References: <20210923130814.140814-1-cgxu519@mykernel.net> <20210923130814.140814-7-cgxu519@mykernel.net> <20211007090157.GB12712@quack2.suse.cz> <17c5ab83d6d.10cdb35ab25883.3563739472838823734@mykernel.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17c5ab83d6d.10cdb35ab25883.3563739472838823734@mykernel.net> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 07-10-21 20:26:36, Chengguang Xu wrote: > ---- 在 星期四, 2021-10-07 17:01:57 Jan Kara 撰写 ---- > > > > > + if (mapping_writably_mapped(upper->i_mapping) || > > > + mapping_tagged(upper->i_mapping, PAGECACHE_TAG_WRITEBACK)) > > > + iflag |= I_DIRTY_PAGES; > > > + > > > + iflag |= upper->i_state & I_DIRTY_ALL; > > > > Also since you call ->write_inode directly upper->i_state won't be updated > > to reflect that inode has been written out (I_DIRTY flags get cleared in > > __writeback_single_inode()). So it seems to me overlayfs will keep writing > > out upper inode until flush worker on upper filesystem also writes the > > inode and clears the dirty flags? So you rather need to call something like > > write_inode_now() that will handle the flag clearing and do writeback list > > handling for you? > > > > Calling ->write_inode directly upper->i_state won't be updated, however, > I don't think overlayfs will keep writing out upper inode since > ->write_inode will be called when only overlay inode itself marked dirty. > Am I missing something? Well, if upper->i_state is not updated, you are more or less guaranteed upper->i_state & I_DIRTY_ALL != 0 and thus even overlay inode stays dirty. And thus next time writeback runs you will see dirty overlay inode and writeback the upper inode again although it is not necessary. Honza -- Jan Kara SUSE Labs, CR