From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f174.google.com ([209.85.220.174]:39490 "EHLO mail-qk0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935923AbeFRTxr (ORCPT ); Mon, 18 Jun 2018 15:53:47 -0400 Received: by mail-qk0-f174.google.com with SMTP id g14-v6so10094609qkm.6 for ; Mon, 18 Jun 2018 12:53:47 -0700 (PDT) Subject: Re: shiftfs status and future development To: Amir Goldstein Cc: James Bottomley , linux-fsdevel , Seth Forshee , Linux Containers , Tyler Hicks , Christian Brauner References: <20180614184448.GC30028@ubuntu-xps13> <20180615135638.GA29299@mail.hallyn.com> <20180615145917.GF30028@ubuntu-xps13> <1529118185.4048.46.camel@HansenPartnership.com> <20180618134032.GP30028@ubuntu-xps13> <1529333819.4021.4.camel@HansenPartnership.com> From: Phil Estes Message-ID: <424a9472-91cb-e7d4-b933-2f8b772782fa@gmail.com> Date: Mon, 18 Jun 2018 15:53:43 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Amir Goldstein wrote on 6/18/18 1:11 PM: > On Mon, Jun 18, 2018 at 5:56 PM, James Bottomley > wrote: > [...] >>>>> - Does not break inotify >>>> I don't expect it does, but I haven't checked. >>> I haven't checked either; I'm planning to do so soon. This is a >>> concern that was expressed to me by others, I think because inotify >>> doesn't work with overlayfs. >> I think shiftfs does work simply because it doesn't really do overlays, >> so lots of stuff that doesn't work with overlays does work with it. >> > I'm afraid shiftfs suffers from the same problems that the old naiive > overlayfs inode implementation suffered from. > > This problem is demonstrated with LTP tests inotify08 inotify09. > shiftfs_new_inode() is called on every lookup, so inotify watch > may be set on an inode object, then dentry is evicted from cache > and then all events on new dentry are not reported on the watched > inode. You will need to implement hashed inodes to solve it. > Can be done as overlay does - hashing by real inode pointer. > > This is just one of those subtle things about stacked fs and there may > be other in present and more in future - if we don't have a shared code > base for the two stacked fs, I wager you are going to end up "cherry > picking" fixes often. > > IMO, an important question to ask is, since both shiftfs and overlayfs > are strongly coupled with container use cases, are there users that > are interested in both layering AND shifting? on the same "mark"? > If the answer is yes, then this may be an argument in favor of > integrating at least some of shittfs functionality into overlayfs. > > Another argument is that shiftfs itself takes the maximum allowed > 2 levels of s_stack_depth for it's 2 mounts, so it is actually not > possible with current VFS limitation to combine shiftfs with overlayfs. I'm not sure if this was my problem or not, but I did try the v2 patchset with overlay (by marking and mounting a filesystem tree with shiftfs, and then using it as the component of an overlay mount) and could not get it to work. I was trying to prepare a demo, but with limited time gave up and wasn't able to find time to debug with possible help from James. I think for shiftfs to be useful in certain container contexts, combination with overlay is definitely a desirable and/or required feature. Of course if it is limited to overlay (e.g. implemented within overlayfs) that would be limiting for container use cases for other contexts (zfs, btrfs, etc.). > > This could be solved relatively easily by adding "-o mark" support > to overlayfs and allowing to mount shiftfs also over "marked" overlayfs > inside container. > > Anyway, I'm just playing devil's advocate to the idea of two stacked fs > implementation, so presenting this point of view. I am fully aware that > there are also plenty of disadvantages to couple two unrelated > functionalities together. > > Cheers, > Amir. > _______________________________________________ > Containers mailing list > Containers@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/containers