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@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
