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... > 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. > > Regarding a layout of the problems, I have a more complete e-mail coming > soon which should describe in detail the issues I've seen with respect to > how the kernel is exporting ino/dev pairs (outside of statx). fs_view alone > is not enough to solve that problem. I'd be happy to CC you on that one if > you'd like. > Sure. [...] >> >> 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? > 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 [...] >> I have an interest of solving another problem. >> In VFS operations where only inode is available, I would like to be able to >> report fsnotify events (e.g. fsnotify_move()) only in directories under a >> certain subtree root. That could be achieved either by bind mount the subtree >> root and passing vfsmount into vfs_rename() or by defining an fs_view on the >> subtree and mounting that fs_view. > > 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. Thanks, Amir.
