Re: [RFC][PATCH 0/76] vfs: 'views' for filesystems with more than one root

[Mark Fasheh]

On Thu, Jun 07, 2018 at 09:06:04AM +0300, Amir Goldstein wrote:
> On Wed, Jun 6, 2018 at 11:42 PM, Mark Fasheh <mfasheh@xxxxxxx> 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