On Mon, Jan 8, 2018 at 5:21 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> 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).
Ah, we do do d_real(path->dentry, NULL, O_WRONLY, 0); from
vfs_truncate(), so that will indeed do a data copy up.
So it should be okay.
Thanks,
Miklos
--
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
