Searched hist:"4849077604 f0126514d487836e7d87c3e53a753c" (Results 1 – 4 of 4) sorted by relevance
/linux/fs/ceph/ |
H A D | addr.c | diff 4849077604f0126514d487836e7d87c3e53a753c Tue Jun 07 04:13:53 CEST 2022 Xiubo Li <xiubli@redhat.com> ceph: don't get the inline data for new creating files
If the 'i_inline_version' is 1, that means the file is just new created and there shouldn't have any inline data in it, we should skip retrieving the inline data from MDS.
This also could help reduce possiblity of dead lock issue introduce by the inline data and Fcr caps.
Gradually we will remove the inline feature from kclient after ceph's scrub too have support to unline the inline data, currently this could help reduce the teuthology test failures.
This is possiblly could also fix a bug that for some old clients if they couldn't explictly uninline the inline data when writing, the inline version will keep as 1 always. We may always reading non-exist data from inline data.
Signed-off-by: Xiubo Li <xiubli@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
|
H A D | super.h | diff 4849077604f0126514d487836e7d87c3e53a753c Tue Jun 07 04:13:53 CEST 2022 Xiubo Li <xiubli@redhat.com> ceph: don't get the inline data for new creating files
If the 'i_inline_version' is 1, that means the file is just new created and there shouldn't have any inline data in it, we should skip retrieving the inline data from MDS.
This also could help reduce possiblity of dead lock issue introduce by the inline data and Fcr caps.
Gradually we will remove the inline feature from kclient after ceph's scrub too have support to unline the inline data, currently this could help reduce the teuthology test failures.
This is possiblly could also fix a bug that for some old clients if they couldn't explictly uninline the inline data when writing, the inline version will keep as 1 always. We may always reading non-exist data from inline data.
Signed-off-by: Xiubo Li <xiubli@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
|
H A D | caps.c | diff 4849077604f0126514d487836e7d87c3e53a753c Tue Jun 07 04:13:53 CEST 2022 Xiubo Li <xiubli@redhat.com> ceph: don't get the inline data for new creating files
If the 'i_inline_version' is 1, that means the file is just new created and there shouldn't have any inline data in it, we should skip retrieving the inline data from MDS.
This also could help reduce possiblity of dead lock issue introduce by the inline data and Fcr caps.
Gradually we will remove the inline feature from kclient after ceph's scrub too have support to unline the inline data, currently this could help reduce the teuthology test failures.
This is possiblly could also fix a bug that for some old clients if they couldn't explictly uninline the inline data when writing, the inline version will keep as 1 always. We may always reading non-exist data from inline data.
Signed-off-by: Xiubo Li <xiubli@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
|
H A D | inode.c | diff 4849077604f0126514d487836e7d87c3e53a753c Tue Jun 07 04:13:53 CEST 2022 Xiubo Li <xiubli@redhat.com> ceph: don't get the inline data for new creating files
If the 'i_inline_version' is 1, that means the file is just new created and there shouldn't have any inline data in it, we should skip retrieving the inline data from MDS.
This also could help reduce possiblity of dead lock issue introduce by the inline data and Fcr caps.
Gradually we will remove the inline feature from kclient after ceph's scrub too have support to unline the inline data, currently this could help reduce the teuthology test failures.
This is possiblly could also fix a bug that for some old clients if they couldn't explictly uninline the inline data when writing, the inline version will keep as 1 always. We may always reading non-exist data from inline data.
Signed-off-by: Xiubo Li <xiubli@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
|