From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59895C71156 for ; Wed, 2 Dec 2020 17:43:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0A8402086A for ; Wed, 2 Dec 2020 17:43:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730916AbgLBRnZ (ORCPT ); Wed, 2 Dec 2020 12:43:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730914AbgLBRnZ (ORCPT ); Wed, 2 Dec 2020 12:43:25 -0500 Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6AC2C061A04; Wed, 2 Dec 2020 09:42:10 -0800 (PST) Received: by mail-io1-xd42.google.com with SMTP id 81so1079930ioc.13; Wed, 02 Dec 2020 09:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SU2667MQNtAIEDDUA9sQyXfNq/LH/Dr/dctHqxLpERE=; b=sgpyQzMIgWTsyfxgCY2mLTF757SetyFuKlcBRuQ/iwmBQP0Eu+a5mMkx+ekzkUxyTl bJFVWJ73+EIEcopDc1n61uRUC2vWcIrNyLkFr7sJCqa8+iGP0hewVw6AEBxrT7jUJYtH m7T/mJGeQnONBUxD4baolU62DMmvT4/pzdYnRuGos7FXiMmdGgsrAqxt27U75Zr2zvzN Jl9ZUMr3bWMUGldk1jbu8GjKjbCH6e9Km60hntvfuioSZsIzN5Hs0VvfxYI6X+HVpHKI 2jRu6i2YSKjaBxg/cO7wvP5c6DBW5neoRZ8VsFTrE5Faq5ENdrciBk55YZCmalbzL303 7zQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SU2667MQNtAIEDDUA9sQyXfNq/LH/Dr/dctHqxLpERE=; b=ory+hh2dHEwR6LSgd0KLYDhF9Xyb770NEImLswpxkqwEnTdeE0SwGfADH9cqsN3Ci3 g+BPEz9r4+BptcAjL7AaNoeYYmqEiMqKKDJNUKYnG8YbotLoGi3taqD3H/qeWquVh2ML pgEtFHJqfG5ryQfqCDNboFALIri+tzLpDShnLm5ywRJXGig4GdW8bURWyrE/7eYjWmlc wAyRFN7xIoIAKk/bCQLvtz3U05/N2jABb0rkltEmHONdzcAZb1AQ9iJCYCQGzluTheoU 9ojSKEJEMvldfYgnqY8gXNy1YObDhbp5yaV2U9/ofeqvnbZGqFHNTSiyH6D3yj4PQixF kxVg== X-Gm-Message-State: AOAM530SlpYUPPd8+TpO6omdE9TiVR/+/YVVxzVVLN3E719pdsIynqkZ kdcCGW3YzcyNE6C7+eNzBz4i2hwpvvkqbvZfBKg= X-Google-Smtp-Source: ABdhPJzgVccBZ3lm0HQ6lozVeGujXueHHWGocCl1fhlxOmyBX611+HaOw+S0c+MsTD93Rrj1P2FQnG04P6iZ/HZIRlI= X-Received: by 2002:a5d:964a:: with SMTP id d10mr2904208ios.5.1606930930065; Wed, 02 Dec 2020 09:42:10 -0800 (PST) MIME-Version: 1.0 References: <20201202092720.41522-1-sargun@sargun.me> <20201202150747.GB147783@redhat.com> In-Reply-To: <20201202150747.GB147783@redhat.com> From: Amir Goldstein Date: Wed, 2 Dec 2020 19:41:59 +0200 Message-ID: Subject: Re: [PATCH] overlay: Implement volatile-specific fsync error behaviour To: Vivek Goyal Cc: Sargun Dhillon , linux-fsdevel , overlayfs , Jeff Layton , Miklos Szeredi Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-unionfs@vger.kernel.org > I asked this question in last email as well. errseq_sample() will return > 0 if current error has not been seen yet. That means next time a sync > call comes for volatile mount, it will return an error. But that's > not what we want. When we mounted a volatile overlay, if there is an > existing error (seen/unseen), we don't care. We only care if there > is a new error after the volatile mount, right? > > I guess we will need another helper similar to errseq_smaple() which > just returns existing value of errseq. And then we will have to > do something about errseq_check() to not return an error if "since" > and "eseq" differ only by "seen" bit. > > Otherwise in current form, volatile mount will always return error > if upperdir has error and it has not been seen by anybody. > > How did you finally end up testing the error case. Want to simualate > error aritificially and test it. > Good spotting! Besides the specialized test for sync error, I wonder if anybody ever tested "volatile" setup with xfstests or unionmount? In xfsftest can set envvar OVERLAY_MOUNT_OPTIONS="-o volatile" In unionmount I have a branch [1] with support for envvar UNIONMOUNT_MNTOPTIONS. I did not merge this change to master because nobody (but me) tested it, so that would be a good opportunity (hint hint) Thanks, Amir. [1] https://github.com/amir73il/unionmount-testsuite/commits/envvars