From patchwork Fri Jun 15 15:46:41 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Seth Forshee X-Patchwork-Id: 10466801 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 3887F601C2 for ; Fri, 15 Jun 2018 15:46:49 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1A01F28DF8 for ; Fri, 15 Jun 2018 15:46:49 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0EBAA28DFD; Fri, 15 Jun 2018 15:46:49 +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=-7.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI 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 7D04E28DFC for ; Fri, 15 Jun 2018 15:46:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965903AbeFOPqr (ORCPT ); Fri, 15 Jun 2018 11:46:47 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:50843 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964778AbeFOPqq (ORCPT ); Fri, 15 Jun 2018 11:46:46 -0400 Received: from mail-io0-f199.google.com ([209.85.223.199]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1fTqw1-0003NI-Dp for linux-fsdevel@vger.kernel.org; Fri, 15 Jun 2018 15:46:45 +0000 Received: by mail-io0-f199.google.com with SMTP id o1-v6so7634482ioa.20 for ; Fri, 15 Jun 2018 08:46:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=CWROk8sfAJsoq2nFS/zl368POC3R4ND43rE9VR6HJII=; b=jPsStqu2ORoBC5H2uvmGAiX/ik65KHwa1YKU7PUUynEuIqMONoSZDNOB5P1KST1vYh K298NG07LF2CDDofJM1ez2Aj11pIIBAOuJHoMORpYlcVrELiHYGeLkWkHR8gW7AcYiqE Lsdxf8q941ZRGU5RR8Lbr2nkXHVrxPXS3tcBWFw4wweTeYS+dVu+tI7Dre4KT2VkgtRD aKd4hwSiKoGV6b1bC00p8dj85OwdAKJGxO9N7kZclc/1VQNik+G/azrHf92syw4CKNCn lpno/IAM7npxGlj6dFD4cg08jns+Bg7dyQUH0P0fftIrFkTlCgwh9kHT+uZ/4869bKQz mrgA== X-Gm-Message-State: APt69E3TEmPMZ24o/j85PRQyJM25AUwG1edPqmFA8oyH3tUYiIKUDvJy fH9r3iDwhI2bYKa+LOEh1XZxl/5/QRnozOTvlXztExKKck9fca6BWM1rPLXKUtCM01POrnNCeXU XE3lnf75U+cx/RIUEYpkdvdwE93y7XWb0qBdI/Kh87x8= X-Received: by 2002:a24:7582:: with SMTP id y124-v6mr1654645itc.115.1529077603127; Fri, 15 Jun 2018 08:46:43 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLuxCRcFXI4JFim0Oib0P7QMzXgHgkfkSAWx86HMU2++/QffHKfwX1Ct/qFGmj/vW4/DA7gTA== X-Received: by 2002:a24:7582:: with SMTP id y124-v6mr1654622itc.115.1529077602860; Fri, 15 Jun 2018 08:46:42 -0700 (PDT) Received: from localhost ([2605:a601:ac6:7f20:f84e:4530:e5fb:3836]) by smtp.gmail.com with ESMTPSA id 16-v6sm1079018itk.17.2018.06.15.08.46.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 15 Jun 2018 08:46:42 -0700 (PDT) Date: Fri, 15 Jun 2018 10:46:41 -0500 From: Seth Forshee To: James Bottomley Cc: containers@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, Tyler Hicks , Christian Brauner Subject: Re: shiftfs status and future development Message-ID: <20180615154641.GH30028@ubuntu-xps13> References: <20180614184448.GC30028@ubuntu-xps13> <1529076534.4048.10.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1529076534.4048.10.camel@HansenPartnership.com> User-Agent: Mutt/1.10.0 (2018-05-17) 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 Fri, Jun 15, 2018 at 08:28:54AM -0700, James Bottomley wrote: > On Thu, 2018-06-14 at 13:44 -0500, Seth Forshee wrote: > > I wanted to inquire about the current status of shiftfs and the plans > > for it moving forward. We'd like to have this functionality available > > for use in lxd, and I'm interesetd in helping with development (or > > picking up development if it's stalled). > > Well, I'm still using it and technically still developing it; it's just > that its self contained and there haven't been any interface changes > necessitating an update that I've noticed, so the last published patch > still applies (well, unless my git rebasing quietly changed something > and I didn't notice). I did have to make some changes when I tried it out with 4.17, see below. > > To start, is anyone still working on shiftfs or similar > > functionality? I haven't found it in any git tree on kernel.org, and > > as far as mailing list activity the last submission I can find is > > [1]. Is there anything newer than this? > > I'm working on it, but it mostly works for my use case. > > > Based on past mailing list discussions, it seems like there was still > > debate as to whether this feature should be an overlay filesystem or > > something supported at the vfs level. Was this ever resolved? > > I think that's the main problem: I don't really have anything > actionable to work on for upstreaming. I suspect growing more > consumers would help with this. Kind of a chicken/egg problem, as it's difficult to grow consumers when it's not upstream. I'm starting to work with it though. However it seems to me that the question of whether or not this should be an overlay filesystem is pretty fundamental. There was a fairly long thread between you and Christoph Hellwig on the topic that didn't really seem to come to a resolution. Thanks, Seth From 70352c549e9c023cd0c0732329a44f5bbcac0ace Mon Sep 17 00:00:00 2001 From: Seth Forshee Date: Thu, 24 May 2018 09:40:13 -0500 Subject: [PATCH] shiftfs: Forward port to 4.17-rc6 Signed-off-by: Seth Forshee --- fs/shiftfs.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/fs/shiftfs.c b/fs/shiftfs.c index ea8ac57b3ce1..fa0797bd7880 100644 --- a/fs/shiftfs.c +++ b/fs/shiftfs.c @@ -109,12 +109,12 @@ static void shiftfs_d_release(struct dentry *dentry) static struct dentry *shiftfs_d_real(struct dentry *dentry, const struct inode *inode, - unsigned int flags) + unsigned int open_flags, unsigned int flags) { struct dentry *real = dentry->d_fsdata; if (unlikely(real->d_flags & DCACHE_OP_REAL)) - return real->d_op->d_real(real, real->d_inode, flags); + return real->d_op->d_real(real, real->d_inode, open_flags, flags); return real; } @@ -545,19 +545,20 @@ static int shiftfs_setattr(struct dentry *dentry, struct iattr *attr) return 0; } -static int shiftfs_getattr(struct vfsmount *mnt, struct dentry *dentry, - struct kstat *stat) +static int shiftfs_getattr(const struct path *path, struct kstat *stat, + u32 request_mask, unsigned int flags) { + struct dentry *dentry = path->dentry; + struct shiftfs_super_info *ssi = dentry->d_sb->s_fs_info; struct inode *inode = dentry->d_inode; struct dentry *real = inode->i_private; struct inode *reali = real->d_inode; const struct inode_operations *iop = reali->i_op; + struct path realpath = { .mnt = ssi->mnt, .dentry = real }; int err = 0; - mnt = dentry->d_sb->s_fs_info; - if (iop->getattr) - err = iop->getattr(mnt, real, stat); + err = iop->getattr(&realpath, stat, request_mask, flags); else generic_fillattr(reali, stat); @@ -625,7 +626,7 @@ static struct inode *shiftfs_new_inode(struct super_block *sb, umode_t mode, * may be aliases plus a few others. */ if (reali) - use_inode_hash = ACCESS_ONCE(reali->i_nlink) > 1 && + use_inode_hash = READ_ONCE(reali->i_nlink) > 1 && !S_ISDIR(reali->i_mode); if (use_inode_hash) {