Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2360338pxb; Fri, 8 Oct 2021 06:19:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzrxQHYOe6Mtr+guhFXlPC/i2fn0oCdBzqYCHadGiUUgfIWMlJ9FEBYDMLE+1uh4ewFVc+k X-Received: by 2002:a05:6402:254e:: with SMTP id l14mr6954957edb.27.1633699160198; Fri, 08 Oct 2021 06:19:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633699160; cv=none; d=google.com; s=arc-20160816; b=mgLcG2FYd2tqjeOz+4SpWKiUlwhqGg69WrbSi1E8z409YRhVnITPIUTs2lqjmwCyad mGip7hiHt0ySDi43RScnoWizrtm7V1bVt0kLvjBm6yxpbFXuQKOnkQct5fwiQridQB0Y maebBy9+IOsRgIbzKtdDvS9I8N/D00K9BELuHM/DZptC2Z8ViLxQsFXcQIlGspKUwOa/ Nc4FJ/wZRn3+5HKMtF91QdaCwPtjlSus72D5wU0ctk8f4/kT8LZOZT4LJB++jRaF4irb 6BGHx+9jFEcS9ZN8MXQIrUYEv3fOl+TBoV6UnTEI1BBLo0LO8hE/2yEX/kWNBDvHMuKr t22w== 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=ugDtUlYWNamC1wVk99SJQfcQCo8cBWNlkB8aWdjRG/Q=; b=vZzR8WBwfA7oEPtyI8Oye96zaZE3H9gQybxjNwu87lXcgLCApU6xpSbsC1S/jefg5m znehCLvcYXYTwxhQzYaqqNtaIODX2NletixLV+8iLYIyzexOxnxhwhmEWWBbGkafkH7K VMnaSOgvlRl4Ha3PM/cnHJJN2fxXGS3YGP8MO0tJ7Q8W3Gj1i3qRaBLbQTDo6BJJlTwr LNE8VjAJU1sa3d5nLDIveYLJ7q57sFQbVZMOEt5LAf5Nnw2IJzijtzprX173Oj6WhJq5 4meNMfYMk0VWfiqhnYEh58fOi7Br4IBfkfcg0uX2xIvtPt8dCRyYlqXH5+1vzkRhdrvB 07QQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=MwaLbrnD; dkim=neutral (no key) header.i=@suse.cz; 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 5si3113719eji.132.2021.10.08.06.18.54; Fri, 08 Oct 2021 06:19:20 -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=MwaLbrnD; dkim=neutral (no key) header.i=@suse.cz; 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 S242632AbhJHNPw (ORCPT + 99 others); Fri, 8 Oct 2021 09:15:52 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:35764 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242558AbhJHNPv (ORCPT ); Fri, 8 Oct 2021 09:15:51 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id D0CFE2012E; Fri, 8 Oct 2021 13:13:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1633698834; 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=ugDtUlYWNamC1wVk99SJQfcQCo8cBWNlkB8aWdjRG/Q=; b=MwaLbrnDI9nPWKefsT9kREclrK/WRJ269jjuYM4JWcuknUEehSkSQblsyg2WBrPK4TpDW9 5rOX7rd0a2RsqGAEEcFhIr+K6DDARnlDsNjHdLvSxfzWzt43ChVc3WJL/0FAZrRZa0hUBj +wFAzKldEBYkS/9ufr6nbYwmvPgkPZU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1633698834; 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=ugDtUlYWNamC1wVk99SJQfcQCo8cBWNlkB8aWdjRG/Q=; b=svewaWRaCt5qQyLUDqoU4/tFzQy7sdFsCCeQMawmWISUqMWFYVfFLOPHUQi8foAljygp9p T81e9w++i7jdiSCg== Received: from quack2.suse.cz (unknown [10.100.224.230]) by relay2.suse.de (Postfix) with ESMTP id 7452BA3B83; Fri, 8 Oct 2021 13:13:54 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id E10321F2C8D; Fri, 8 Oct 2021 15:13:51 +0200 (CEST) Date: Fri, 8 Oct 2021 15:13:51 +0200 From: Jan Kara To: Miklos Szeredi Cc: Chengguang Xu , Jan Kara , Amir Goldstein , linux-fsdevel , overlayfs , linux-kernel Subject: Re: [RFC PATCH v5 06/10] ovl: implement overlayfs' ->write_inode operation Message-ID: <20211008131351.GA15930@quack2.suse.cz> References: <20210923130814.140814-1-cgxu519@mykernel.net> <20210923130814.140814-7-cgxu519@mykernel.net> <17c5aba1fef.c5c03d5825886.6577730832510234905@mykernel.net> <17c5adfe5ea.12f1be94625921.4478415437452327206@mykernel.net> <20211007144646.GL12712@quack2.suse.cz> <17c5b3e4f2b.113dc38cd26071.2800661599712778589@mykernel.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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:51:47, Miklos Szeredi wrote: > On Thu, 7 Oct 2021 at 16:53, Chengguang Xu wrote: > > > > ---- 在 星期四, 2021-10-07 22:46:46 Jan Kara 撰写 ---- > > > On Thu 07-10-21 15:34:19, Miklos Szeredi wrote: > > > > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu wrote: > > > > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > > > > won't start write back for dirty pages. Maybe I'm missing something, > > > > > > but there it looks as if nothing will actually trigger writeback for > > > > > > dirty pages in upper inode. > > > > > > > > > > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > > > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > > > > > > > Right. > > > > > > > > But wouldn't it be simpler to do this from ->write_inode()? > > > > > > You could but then you'd have to make sure you have I_DIRTY_SYNC always set > > > when I_DIRTY_PAGES is set on the upper inode so that your ->write_inode() > > > callback gets called. Overall I agree the logic would be probably simpler. > > > > > > > And it's not just for simplicity. The I_SYNC logic in > writeback_single_inode() is actually necessary to prevent races > between instances on a specific inode. I.e. if inode writeback is > started by background wb then syncfs needs to synchronize with that > otherwise it will miss the inode, or worse, mess things up by calling > ->write_inode() multiple times in parallel. So going throught > writeback_single_inode() is actually a must AFAICS. Yes, you are correct. Honza -- Jan Kara SUSE Labs, CR