Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp6055219pxu; Wed, 23 Dec 2020 12:10:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJwAnD8iJP7QcUaUzgAz3233jJB0P6JUh1CaHpREUMmJDTHRgyZXYe2zqR9Gh4JzcEtAbC0c X-Received: by 2002:a05:6402:139a:: with SMTP id b26mr26239209edv.47.1608754201310; Wed, 23 Dec 2020 12:10:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608754201; cv=none; d=google.com; s=arc-20160816; b=EhnmPX0GzFGjjYQKEx2tRI7/8QVha2TKi7ILPHd8Cd7L7CPd2Q4f37cIUoAWo7FjCr +L2lTgltqsLZMK8KW0JDgDdMYnPiN1VP966Ws5RNhTVEi/fCpp0ujTYTZ0i8sxiVrEqY X/SP2SeuPw7E5XqDDkKcHo7INshOWbQe08wTHK/U3NSrAKeOXYRcWSG3utk87X0Q3dBT Dn0t0jFVsHP1hyRQctO8yC8fXKZbVNzqR0bpbLwsYuz1xfNSwOZ8SRGFdlTNAc85JRr/ InexknVbQCu5IJc+CdzLqqQgwutDUtg/RUpAkflUaZve9ejyUoLAFcyydNw3/awYB8UG Rk8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=JqAs7/IqK/ESG/Ka9oK25ik6wVg0igAJShtBSVYvteg=; b=WwU12mGxn6JUF9zju7fe4GZTEJczZjyWsCYsyxXgr+SvDvwDsakS9Y3o5Y75rubZsG hvyBrp2LZIrUFYDs4JNRvLsHfKpmCY3QFwae9rt8c0VIXE4eRkj2IsAYUQ9K0TXtgLpW IGmcrsJuTzLv0cEMcyNooTZOjWLPM3vvZKv3smFEW+1kcYtWPOL0mzOnRscucvNev3if +n5xNzvK1tcXU0GPlc8eRnuXjfv4EaX8kueHOzJpxb1S7TEnEClGhisYozpVFwpWDf7F vjuqfrfZfzVSoXtRy7w0zB24ildXbK7FvawuPgT5JGaRxlfWNBcwzNgq1Ap3G3awAUDM SuKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=elzZw5E5; 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 m3si8874394ejn.166.2020.12.23.12.09.38; Wed, 23 Dec 2020 12:10:01 -0800 (PST) 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=@infradead.org header.s=casper.20170209 header.b=elzZw5E5; 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 S1728722AbgLWUIa (ORCPT + 99 others); Wed, 23 Dec 2020 15:08:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727671AbgLWUIa (ORCPT ); Wed, 23 Dec 2020 15:08:30 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DACCEC061794; Wed, 23 Dec 2020 12:07:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=JqAs7/IqK/ESG/Ka9oK25ik6wVg0igAJShtBSVYvteg=; b=elzZw5E5Vk0tIi7tAwVX+Jr2j6 bdRWFl/AsoFrR3ZXNZ3/LOskVP+LQK3uhA8TsdM0ipj+0kAbaQ6etRqsEGUfuCeM2m2pgO37Y+FKB WUrX7vn42dRYR6wHBnNGseflCneg/D2nMAiyvDzQqrVpuvAqGF4KoLqi+OVf7Rh27Nic6/jliSEnI K7tVzNrI7RmNgoWlRgiiJms0tj32zWllxNbRS/ScbtIO2uVVIrdj+yp2jC40qRMNssvEy/Ef8BSZE Dm3P8YaqF1BhXaXXHeHKss4pfygaIMaVNtTQbKw/MRS892HN3GJrkuAFEKvpvKzEm8y6AIR2T1lAK UHxwPZRg==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1ksAQE-0008P2-Su; Wed, 23 Dec 2020 20:07:47 +0000 Date: Wed, 23 Dec 2020 20:07:46 +0000 From: Matthew Wilcox To: Sargun Dhillon Cc: Vivek Goyal , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-unionfs@vger.kernel.org, jlayton@kernel.org, amir73il@gmail.com, miklos@szeredi.hu, jack@suse.cz, neilb@suse.com, viro@zeniv.linux.org.uk, hch@lst.de Subject: Re: [PATCH 3/3] overlayfs: Report writeback errors on upper Message-ID: <20201223200746.GR874@casper.infradead.org> References: <20201221195055.35295-1-vgoyal@redhat.com> <20201221195055.35295-4-vgoyal@redhat.com> <20201223182026.GA9935@ircssh-2.c.rugged-nimbus-611.internal> <20201223185044.GQ874@casper.infradead.org> <20201223192940.GA11012@ircssh-2.c.rugged-nimbus-611.internal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201223192940.GA11012@ircssh-2.c.rugged-nimbus-611.internal> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 23, 2020 at 07:29:41PM +0000, Sargun Dhillon wrote: > On Wed, Dec 23, 2020 at 06:50:44PM +0000, Matthew Wilcox wrote: > > On Wed, Dec 23, 2020 at 06:20:27PM +0000, Sargun Dhillon wrote: > > > I fail to see why this is neccessary if you incorporate error reporting into the > > > sync_fs callback. Why is this separate from that callback? If you pickup Jeff's > > > patch that adds the 2nd flag to errseq for "observed", you should be able to > > > stash the first errseq seen in the ovl_fs struct, and do the check-and-return > > > in there instead instead of adding this new infrastructure. > > > > You still haven't explained why you want to add the "observed" flag. > > > In the overlayfs model, many users may be using the same filesystem (super block) > for their upperdir. Let's say you have something like this: > > /workdir [Mounted FS] > /workdir/upperdir1 [overlayfs upperdir] > /workdir/upperdir2 [overlayfs upperdir] > /workdir/userscratchspace > > The user needs to be able to do something like: > sync -f ${overlayfs1}/file > > which in turn will call sync on the the underlying filesystem (the one mounted > on /workdir), and can check if the errseq has changed since the overlayfs was > mounted, and use that to return an error to the user. OK, but I don't see why the current scheme doesn't work for this. If (each instance of) overlayfs samples the errseq at mount time and then check_and_advances it at sync time, it will see any error that has occurred since the mount happened (and possibly also an error which occurred before the mount happened, but hadn't been reported to anybody before). > If we do not advance the errseq on the upperdir to "mark it as seen", that means > future errors will not be reported if the user calls sync -f ${overlayfs1}/file, > because errseq will not increment the value if the seen bit is unset. > > On the other hand, if we mark it as seen, then if the user calls sync on > /workdir/userscratchspace/file, they wont see the error since we just set the > SEEN flag. While we set the SEEN flag, if the file were opened before the error occurred, we would still report the error because the sequence is higher than it was when we sampled the error.