On Thu, Jan 31, 2013 at 6:01 PM, J. R. Okajima <hooanon05@xxxxxxxxxxx> wrote:
>
> Miklos Szeredi:
>> One issue, though, is that stat("x") and fd=open("x"); fstat(fd) will
>> return different file stats (the fstat one will return the stats for
>> the original file). This may confuse some apps.
>>
>> This is a something a "true" union filesystem can do better that
>> union-mounts or overlayfs.
>
> Exactly.
> That was one example I picked up and posted when I read overlayfs years
> ago.
> Recently I named it "name-based union". Of course AUFS is "inode-based
> union." stat(2) operates upon a filename while fstat(2) operates upon a
> file descriptor. Overlayfs (and probably UnionMount too) may return
> different info for these two systemcalls even when they should be equal.
> All the inode-based (or file descriptor based) operations can confuse
> users in overlayfs, I am afraid. I was looking forward to see how
> overlayfs solve this problem.
They don't "solve" this, it's a fundamental property of the
implementation. Overlayfs and union-mounts behave as if copy-up was a
"bind mount" over the file in question. Yes, it's a namespace trick
but it seems to work in most situations.
>
> Overriding uid/gid is an idea, but obviously it will not match using
> with system dirs such as /bin and /usr, since they often have suid
> binaries. So it will be used only for user dirs which is unioned as
> lower RO layer. It might be better to implement such feature into your
> lower FS (or generic VFS feature) instead of overlayfs.
> If I remember correctly, some non-unix FS such as VFAT already have such
> feature.
The point was that uid/gid was to be overridden with *different*
values for each overlayfs instance. So implementing uid/gid
overriding in the lower fs doesn't help.
Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
