From patchwork Tue Feb 14 14:01:45 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 9572059 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id CA8F760578 for ; Tue, 14 Feb 2017 14:04:09 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BC11627D4D for ; Tue, 14 Feb 2017 14:04:09 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B039A27FA8; Tue, 14 Feb 2017 14:04:09 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 515B2271BC for ; Tue, 14 Feb 2017 14:04:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753236AbdBNOD0 (ORCPT ); Tue, 14 Feb 2017 09:03:26 -0500 Received: from mail-ot0-f173.google.com ([74.125.82.173]:33285 "EHLO mail-ot0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753221AbdBNOBw (ORCPT ); Tue, 14 Feb 2017 09:01:52 -0500 Received: by mail-ot0-f173.google.com with SMTP id 73so93104177otj.0; Tue, 14 Feb 2017 06:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CmkOBy58a9srkZQm+GH4Yc4SHiO02DudK8NAV8KTKiQ=; b=PANTnPFjQLU8Ng4h2BA4wtTSjBDwS/bRHYiv0Eh71ACUVJtF5Fpo4XTthZbYY0fzos 5W9b28leCpmOQzPRFlwF8H6SSh+UsLqbS+Adzc2Zj7MEkd5v5WlkNbjDltorYB5nxqLA DvyNBoFajIV0QVT9BSs5CxZfUfRAUzQCgYkGqp7/ZoDd1K6dU098WLP//I3aV0WpOXxS WNjxiaxAibTvgUflyogdC2Z6Slz+7D1GSKYtdoj3LwUKbinhnxc3mBctNgMqXBwiUG9W NC6Zh8M12pri99CkVAQukqxGMrTDOMl1Mvu7Mba3lTMPfeDjpgKuL5gco2Dt05QC4YPK FJxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CmkOBy58a9srkZQm+GH4Yc4SHiO02DudK8NAV8KTKiQ=; b=ScGCcp9I9UOzvaHlXK2rQTfzN9sFHMwZWM+iamDGQtgUs7XKqTcdJh+b8bmybdPMxa dEYj5qH8NHo/MvODs79PGUpehbImO32pSQEXaAxIljNXnm1Eq8DeLdouXocSeZvOV+Au +5h4cHBsnl2rZ9EXYYeIxcrA5GAfnEGiXDSFrBIrNvX2Cmwn8IZ/wgI452m+q+sbaJfi 87oswowVf3NHjCnkEwuZlP6jaravro5sSXG520eC3XRcazDUc9ELYK0e8fEVoWS1Bsp/ JPhqIvdSYJ8UcCX67bdoygqEMu5faW2odX/m5qmqVqbRnaCJGis4G00bv9RWwLjmAtzX 3c8g== X-Gm-Message-State: AMke39mf3VcYR9BD2l6zcKZwPezSv0PDVTm2K+dnmGZrxiuQrelW+Oqem9NagTP+g+EJB7NQZwg6DNSvI/Gyog== X-Received: by 10.157.49.38 with SMTP id e35mr14814373otc.196.1487080906056; Tue, 14 Feb 2017 06:01:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.162.70 with HTTP; Tue, 14 Feb 2017 06:01:45 -0800 (PST) In-Reply-To: References: From: Amir Goldstein Date: Tue, 14 Feb 2017 16:01:45 +0200 Message-ID: Subject: Re: overlayfs: allowing for changes to lowerdir To: Josh England Cc: linux-fsdevel , linux-unionfs@vger.kernel.org, Miklos Szeredi Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Feb 13, 2017 at 11:41 PM, Josh England wrote: > So here's the use case: lowerdir is an NFS mounted root filesystem > (shared by a bunch of nodes). upperdir is a tmpfs RAM disk to allow > for writes to happen. This works great with the caveat being I cannot > make 'live' changes to the root filesystem, which poses the problem. > Any access to a changed file causes a 'Stale file handle' error. > > With some experimenting, I've discovered that remounting the overlay > filesystem (mount -o remount / /) registers any changes that have > been made to the lower NFS filesystem. In addition, dumping cache > (via /proc/sys/vm/drop_caches) also makes the stale file handle errors > go away and reads pass through to the lower dir and correctly show > changes. > > I'd like to make this use case feasible by allowing changes to the NFS > lowerdir to work more or less transparently. It seems like if the > overlay did not do any caching at all, all reads would fall through to > either the upperdir ram disk or the NFS lower, which is precisely what > I want. > > So, let me pose this somewhat naive question: Would it be possible to > simply disable any cacheing performed by the overlay to force all > reads to go to either the tmpfs upper or the (VFS-cached) NFS lower? > Would this be enough to accomplish my goal of being able to change the > lowerdir of an active overlayfs? > There is no need to disable caching. There is already a mechanism in place in VFS to revalidate inode cache entries. NFS implements d_revalidate() and overlayfs implements d_revalidate() by calling into the lower fs d_revalidate(). However overlayfs intentionally errors when lower entry has been modified. (see: 7c03b5d ovl: allow distributed fs as lower layer) You can try this (untested) patch to revert this behavior, just to see if it works for your use case, but it won't change this fact from Documentation/filesystems/overlayfs.txt: " Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed. If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in a crash or deadlock." Specifically, renaming directories and files in lower that were already copied up is going to have a weird outcome. Also, the situation with changing files in lower remote fs could be worse than changing files on lower local fs, simply because right now, this use case is not tested (i.e. it results in ESTALE). I believe that fixing this use case, if at all possible, would require quite a bit of work, a lot of documentation (about expected behavior) and even more testing. Amir. diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c index e8ef9d1..6806ef3 100644 --- a/fs/overlayfs/super.c +++ b/fs/overlayfs/super.c @@ -106,16 +106,11 @@ static int ovl_dentry_revalidate(struct dentry *dentry, unsigned int flags) if (d->d_flags & DCACHE_OP_REVALIDATE) { ret = d->d_op->d_revalidate(d, flags); - if (ret < 0) + if (ret =< 0) return ret; - if (!ret) { - if (!(flags & LOOKUP_RCU)) - d_invalidate(d); - return -ESTALE; - } } } - return 1; + return ret; }