Re: two questiones about overlayfs

[Vivek Goyal <vgoyal@redhat.com>]

On Wed, Aug 16, 2017 at 06:12:57PM +0200, Amir Goldstein wrote:
> On Wed, Aug 16, 2017 at 3:52 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Wed, Aug 16, 2017 at 12:19:22PM +0200, Miklos Szeredi wrote:
> ...
> >>
> >> What about copy up of flags?  Should we?  Does reflink copy the flags?
> >
> > Oh yes, copy up of flags seem to be an issue too. I have a file on lower
> > with project id 123 and once that file gets copied up, project id goes
> > back to 0.
> >
> > [merged]# lsattr -p foo.txt
> >   123 ------------------- foo.txt
> >
> > [merged]# touch foo.txt
> >
> > [merged]# lsattr -p foo.txt
> >     0 ------------------- foo.txt
> >
> 
> Vivek,
> 
> This specific case I would tag as "desired behavior".
> This is the behavior that allowed us to implement container storage quota
> for docker using overlayfs + project quota set on overlay upper dir.
> Copy up file inherits its project quota id from upper dir recursively, which
> at least for docker use case is "desired behavior"

Hi Amir,

I am not quota expert but it kind of makes sense to me. So when a file is
copied up it is a newly created file which will inherit its project id from its
parent directory (or ancestor), instead of trying to retain project id
from lower/.

> 
> IMO, for the KSTAT_ATTR_FS_IOC_FLAGS use case, copy up flags
> (compressed, encrypted, immutable, append, nodump) all make sense,
> although immutable/append should be set after copying data while
> encrypted/compressed should probably be set before copying data??

Sounds reasonable to me.

Vivek