On Wed, Oct 24, 2018 at 5:34 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Mon, Sep 3, 2018 at 8:12 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > When encoding a file handle from lower nested overlayfs, prepending > > another ovl_fh header for nested overlay file handle adds no new > > information for decoding. Instead, we just set a 'nested' flag in ovl_fh > > header for nested file handle, so we know to distinguish between real > > upper file handle that should be decoded from real upper layer and > > nested upper file handle that should be decoded from nested lower layer. > > For the maximum allowed overlay nesting depth of 1, one bit is enough. > > This is an optimization, right? > Optimization was not my motivation. It started off as a patch to enable NFS export for nested overlay, which I needed for snapshots, but then I relaxed uuid requirement and nested overlay NFS export just worked (I think - need to re-check) Then it felt a bit silly to double encode, so posted this patch with its current title, because it did not change functionality anymore, but... > What are the user-visible advantages that would justify the added complexity? > ...When you put it this way, it's really hard to justify the patch on its own. One thing that comes to mind w.r.t. advantages of compact representation of ovl_fh is in-inode xattrs space, but that is quite a far fetched justification. If we wanted more compact xattrs we should have started with shorter names... So feel free to drop this patch. If I ever come with a better reason, I will re-post it. Thanks, Amir.
