On Mon, Jan 8, 2018 at 5:17 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
> On Mon, Jan 08, 2018 at 04:50:00PM +0100, Miklos Szeredi wrote:
>> On Wed, Nov 29, 2017 at 4:54 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
>> > Now we will have the capability to have upper inodes which might be only
>> > metadata copy up and data is still on lower inode. So add a new xattr
>> > OVL_XATTR_METACOPY to distinguish between two cases.
>>
>> Maybe I missed something, but I think there's a bug in this patch:
>> truncate() is a metadata+data operation since it affects results of
>> read(). So it should be handled by doing the data copy-up like we did
>> before.
>
> Hi Miklos,
>
> For truncate operation, we don't do metadata only copy up and fall back
> to regular operation.
>
> ovl_need_meta_copy_up() {
> if (flags && ((OPEN_FMODE(flags) & FMODE_WRITE) || (flags & O_TRUNC)))
> return false;
>
> }
>
> So behavior should not change with metacopy for truncate operation.
>
> Am I missing something?
I'm talking about truncate(2). That will bypass opening the file
completely, going only through ovl_setattr(), which will do a metadata
only copy up (AFAICS).
Thanks,
Miklos
>
> Thanks
> 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
