From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.codeaurora.org by pdx-caf-mail.web.codeaurora.org (Dovecot) with LMTP id xhHFISCZGVseCgAAmS7hNA ; Thu, 07 Jun 2018 20:44:35 +0000 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 2CF046074D; Thu, 7 Jun 2018 20:44:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by smtp.codeaurora.org (Postfix) with ESMTP id 7751360115; Thu, 7 Jun 2018 20:44:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 7751360115 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932543AbeFGUoc (ORCPT + 25 others); Thu, 7 Jun 2018 16:44:32 -0400 Received: from mx2.suse.de ([195.135.220.15]:37950 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750892AbeFGUoa (ORCPT ); Thu, 7 Jun 2018 16:44:30 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id CD0B1AD77; Thu, 7 Jun 2018 20:44:28 +0000 (UTC) Date: Thu, 7 Jun 2018 22:44:28 +0200 From: Mark Fasheh To: Amir Goldstein Cc: Jeff Mahoney , Dave Chinner , linux-fsdevel , linux-kernel , Linux Btrfs , Miklos Szeredi , David Howells , Jan Kara Subject: Re: [RFC][PATCH 0/76] vfs: 'views' for filesystems with more than one root Message-ID: <20180607204428.GA28053@wotan.suse.de> Reply-To: Mark Fasheh References: <20180508180436.716-1-mfasheh@suse.de> <20180508233840.GM10363@dastard> <20180509064103.GP10363@dastard> <5b2ae799-1595-c262-7b65-41b10c11906d@suse.com> <20180606204215.GD9445@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: SUSE Labs User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 07, 2018 at 09:06:04AM +0300, Amir Goldstein wrote: > On Wed, Jun 6, 2018 at 11:42 PM, Mark Fasheh wrote: > > Hi Amir, thanks for the comments! > > > > Hi Mark, > > [...] > > > > Btw, sorry that the name is confusing. I've never been good at picking them. > > Didn't say that it was confusing. It might very well be the perfect name... > if I only knew what sort of thing we are trying to name... Fair enough :) > > That said, if you have a minute to check out the first patch or two you'll > > see that the patches are basically putting a struct in between the super > > block and the inode. > > > > > > One thing I'd like to politely suggest is that anyone now following this > > conversation to please read the at least the first patch. It's an easy read > > and I feel like the conversation overall would be much more clear if > > everyone understood what we're going for. I worry that I didn't do a > > particularly good job explaining the actual code changes. > > > > https://www.spinics.net/lists/linux-fsdevel/msg125492.html > > > > > I did look at the patches. They look simple and clean and they solve A problem. > All I'm saying is that we should look at the set of problems that we know of > before we design an abstraction layer. Agreed, I think my more recent e-mail does a much better job of laying out the issues we're seeing here. > >> And what is the SUSE way? > > > > At SUSE, we carry a version of this patch: > > > > https://marc.info/?l=linux-btrfs&m=130532890824992&w=2 > > > > Essentially a callback which was rejected for various reasons. > > > > Don't see a patch here. Wrong link? That was the 0/2 mail in the patch series. Here are the next two, which contain the actual patches: https://marc.info/?l=linux-btrfs&m=130532892525016&w=2 https://marc.info/?l=linux-btrfs&m=130532899325091&w=2 Keep in mind that the patch has evolved since then though it's essentially the same idea - use a callback where we need to get the correct device. > > The fs_view work was intended to replace that patch with an upstream > > solution. > > > > > > [...] > > >> > >> FYI, the Overlayfs file/inode mapping is about to change with many > >> VFS hacks queued for removal, so stay tuned. > >> > >> [...] > > > > Actually, would you mind giving me a pointer to this work? I'd be very > > interested to see what exactly might be changing. > > > > Mostly, less VFS code is going to be exposed to underlying inode: > > https://marc.info/?l=linux-fsdevel&m=152760014530531&w=2 > > [...] Awesome, thanks for the link Amir. > > I'm not sure whether fs_view works for this. Taking a quick look at > > fsnotify, the state is already on the inode? If there's a globabl fsnotify > > state that needs to be per subtree than yes we could move that to the > > fs_view and you'd simply deref it from the inode struct. > > > > That was my thinking. I have patches to attach an fsnotify mark > to super block. If fs_view could have a root that is different than > super block's root and if file system can guaranty that objects > cannot be moved outside of fs_view root, then fsnotify mark > could be attached to fs_view. Ahh yeah so in that case we could have the mark on the fs_view instead of the superblock and you'd deref it from the inode to get to that inodes root. Thanks, --Mark