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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 BEA6EC35247 for ; Tue, 4 Feb 2020 19:16:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 86ADD2087E for ; Tue, 4 Feb 2020 19:16:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=szeredi.hu header.i=@szeredi.hu header.b="a+K+LZWc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727442AbgBDTQw (ORCPT ); Tue, 4 Feb 2020 14:16:52 -0500 Received: from mail-il1-f193.google.com ([209.85.166.193]:40022 "EHLO mail-il1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727314AbgBDTQv (ORCPT ); Tue, 4 Feb 2020 14:16:51 -0500 Received: by mail-il1-f193.google.com with SMTP id i7so16884321ilr.7 for ; Tue, 04 Feb 2020 11:16:50 -0800 (PST) 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; bh=N9/6XU2LpZWsBgzTzP/hhFG+SEvjhrm1Akh+4LB2jFQ=; b=a+K+LZWcvBn/Qen+mTbm7223lprh5qcBn4n03M+j1wt01jaRqnWZdiVfg8OXtoJRuv jsFJk1c/r2LP7mJnsYPJCuY09T0w7SMu45sZvs8mlUdxbkANMu9bUNkqywhtzLwrWCUH Y5I3ZpOtvK5+VQCI2CCizK69Gkl6kx/0lPYyY= 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=N9/6XU2LpZWsBgzTzP/hhFG+SEvjhrm1Akh+4LB2jFQ=; b=tbamXL6BW+5OGGoWJtenXFIHknH3z2y2L+ymLpfrMlUTI/XX+DVZyzATFfPyE9+VwU y66u+IJRWCVVAUEX+0NRnAn0U7jCXxWZdI/ysVXKdmcA65MpICUrTFaQT/BsD4MrNBkw cAl/y0Y1OpZDjx/bepQa/nsNSXVWo3dR32R6n5ewRCc9cGQH8IJxI8HxX8Qfcn4YGhVm Z1I5X5mRXakvfAcnjScTV46nbYzAy5VPrA4EB6yC5a22M8lRF1XamnrVokZsPpdJLWVV SB6FkJOZdTwafYanlhmNCJz7SXE52s26rIOyj7bnfqp3+LQZ9E1+CNIVhn1jkCvjNAUz eRCw== X-Gm-Message-State: APjAAAWOixuZAWPfWvJ//8mGONDp8IpAOavF2V0Bx54Oz7cVBHeAFTK6 NeWvXWhtM3Mp30hsQMrl2wUz/3g1UhGd3B0g5F00QQ== X-Google-Smtp-Source: APXvYqwBCrb0c3k8/h5XEMaUEVvPRrRnwM6U/8qzM3bVAInIClMbhx20heV2frId/eht16ldh1qeEDwL4qHGTjKjEIg= X-Received: by 2002:a92:3c93:: with SMTP id j19mr20659572ilf.63.1580843809908; Tue, 04 Feb 2020 11:16:49 -0800 (PST) MIME-Version: 1.0 References: <20200131115004.17410-1-mszeredi@redhat.com> <20200131115004.17410-5-mszeredi@redhat.com> <20200204145951.GC11631@redhat.com> <20200204184221.GA24566@redhat.com> In-Reply-To: From: Miklos Szeredi Date: Tue, 4 Feb 2020 20:16:39 +0100 Message-ID: Subject: Re: [PATCH 4/4] ovl: alllow remote upper To: Amir Goldstein Cc: Vivek Goyal , Miklos Szeredi , overlayfs , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue, Feb 4, 2020 at 8:11 PM Amir Goldstein wrote: > > On Tue, Feb 4, 2020 at 8:42 PM Vivek Goyal wrote: > > So as of now user space will get -ESTALE and that will get cleared when > > user space retries after corresponding ovl dentry has been dropped from > > cache (either dentry is evicted, cache is cleared forcibly or overlayfs > > is remounted)? If yes, that kind of makes sense. Overlay does not expect > > underlying layers to change and if a change it detected it is flagged > > to user space (and overlayfs does not try to fix it)? > > > > I looks like it. I don't really understand why overlayfs shouldn't drop > the dentry on failure to revalidate. Maybe I am missing something. I don't remember the exact reason. Maybe it's just that it makes little sense to redo the lookup on remote change, but not on local change... Note: I'm not against detection of changing underlying layers and redoing the lookup in that case. Maybe we can do it optionally (because it could be expensive), but first there needs to be a use case and we seem to lack that. Thanks, Miklos