You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ozone.apache.org by Rakesh Radhakrishnan <ra...@apache.org> on 2021/04/05 09:44:00 UTC
[VOTE] - Merge FileSystem Optimizations branch HDDS-2939 to master
Hi All,
I would like to propose prefix based FileSystem Optimizations (FSO) work
HDDS-2939 <https://issues.apache.org/jira/browse/HDDS-2939> merging into
Ozone master branch. This optimization is intended to support atomic rename
and delete operations in Ozone namespace.
Presently, a rename/delete operation can become prohibitively expensive for
such directories which have large sub-trees/sub-paths. This optimization
allows to perform rename, delete of any directory in a
deterministic/constant time atomically.
The main functionality has been implemented and supports o3fs, ofs and
ObjectStore APIs, for details please refer to sub-tasks of HDDS-2939 which
we have been actively working in the feature branch
<https://github.com/apache/ozone/tree/HDDS-2939> for the last several
months. There is a configuration to turn this feature ON and OFF while
merging back to master, it will be turned OFF by default for now.
Merging back to master will greatly help in stabilizing/testing the feature
more rigorously while ensuring the ongoing work on the master branch is not
negatively impacted by the feature as it is turned OFF by default.
Following graph compares the performance between master(V0) and new
optimized code(V1) for the delete op in an unsecure cluster. Rename op also
has similar results. Please refer to the attached test report
<https://issues.apache.org/jira/secure/attachment/13023395/Performance+Comparison+Between++Master+and+HDDS-2939+branch-Report-001.pdf>in
jira for more details.
*Ozone wiki page:*
https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
Number of JIRAs Resolved: 27
Patch Available/WIP: 3 jira
There are few ongoing sub-tasks, IMHO they are blockers for merge. We will
be actively working on these sub-tasks.
Detailed design document is available in JIRA :
https://issues.apache.org/jira/secure/attachment/12991926/Ozone%20FS%20Namespace%20Proposal%20v1.0.docx
https://issues.apache.org/jira/secure/attachment/13023399/OzoneFS%20Optimizations_DesignOverview_%20HDDS-2939.pdf
Quick stats on combined HDDS-2939 Patch : Commits
8b8a7e3ec84ad14e7128ff5fb3ded542ea9080d7..6d76676d2956346895de630a96c182188f9f3e38
157 files changed, 16289 insertions(+), 776 deletions(-)
Added/modified test cases= ~160
Thanks a lot to all contributors/reviewers.
So, I feel this branch is ready to merge into master branch. Could you
please provide your feedback. If there are no objections, I will proceed
for merge voting.
Thanks,
Rakesh
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to master
Posted by Rakesh Radhakrishnan <ra...@apache.org>.
>>> Currently, I see listKey implementation and key deletion lifecycle in
FSO hasn't been completed yet.
Thanks a lot Yiqun for the great support. Sure, I will focus on these two
cases.
As we know, basic #listKeys has been supported via HDDS-4683 sub-task and I
need to extend it to support #listKeys with startKey parameter. I will work
on this in HDDS-4859 sub-task.
I've addressed your comments in DirectoryDeletionService PR_2093
<https://github.com/apache/ozone/pull/2093>. Thanks again for the useful
review comments. Once PR-2093 is finished, then I will put up a test patch
to verify KeyDeletionService file blocks cleanup via HDDS-5042 sub-task.
Thanks,
Rakesh
On Mon, Apr 5, 2021 at 8:04 PM Lin, Yiqun <yi...@ebay.com.invalid> wrote:
> +1 for merging to master after resolved current few block subtasks.
> Currently, I see listKey implementation and key deletion lifecycle in FSO
> hasn't been completed yet.
>
> On 2021/4/5, 5:49 PM, "Rakesh Radhakrishnan" <ra...@apache.org> wrote:
>
> External Email
>
> Hi All,
>
> I'm really sorry for the wrong subject line. It is a [DISCUSS] thread
> and
> not a VOTE thread.
>
> Please excuse me.
>
> Thanks,
> Rakesh
>
>
> On Mon, Apr 5, 2021 at 3:14 PM Rakesh Radhakrishnan <
> rakeshr@apache.org>
> wrote:
>
> > Hi All,
> >
> > I would like to propose prefix based FileSystem Optimizations (FSO)
> work
> > HDDS-2939 <
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FHDDS-2939&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C1oe4PHLRrGQY9xQ34Zb53JhfRW8tDSKZWOnGe2SNSo%3D&reserved=0>
> merging into
> > Ozone master branch. This optimization is intended to support atomic
> rename
> > and delete operations in Ozone namespace.
> >
> > Presently, a rename/delete operation can become prohibitively
> expensive
> > for such directories which have large sub-trees/sub-paths. This
> > optimization allows to perform rename, delete of any directory in a
> > deterministic/constant time atomically.
> >
> > The main functionality has been implemented and supports o3fs, ofs
> and
> > ObjectStore APIs, for details please refer to sub-tasks of HDDS-2939
> which
> > we have been actively working in the feature branch
> > <
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fozone%2Ftree%2FHDDS-2939&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kfP%2Fo6LppbkODnzR326CdsIQCtniXrzeVQXflzYTP%2Fo%3D&reserved=0>
> for the last several
> > months. There is a configuration to turn this feature ON and OFF
> while
> > merging back to master, it will be turned OFF by default for now.
> >
> > Merging back to master will greatly help in stabilizing/testing the
> > feature more rigorously while ensuring the ongoing work on the master
> > branch is not negatively impacted by the feature as it is turned OFF
> by
> > default.
> >
> > Following graph compares the performance between master(V0) and new
> > optimized code(V1) for the delete op in an unsecure cluster. Rename
> op also
> > has similar results. Please refer to the attached test report
> > <
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2Fattachment%2F13023395%2FPerformance%2BComparison%2BBetween%2B%2BMaster%2Band%2BHDDS-2939%2Bbranch-Report-001.pdf&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s1AvJFVIIglI8ZGW0z11CdkpyQH02zg3Dm8vlDcCsO0%3D&reserved=0
> >in
> > jira for more details.
> >
> > *Ozone wiki page:*
> >
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FOZONE%2FFileSystem%2BOptimizations%2B-%2BHDDS-2939&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KV1SDaXCvHMFmYovH1mqh%2BXcc1QqbvOcVMho9Sq4bOc%3D&reserved=0
> >
> > Number of JIRAs Resolved: 27
> >
> > Patch Available/WIP: 3 jira
> >
> > There are few ongoing sub-tasks, IMHO they are blockers for merge.
> We will
> > be actively working on these sub-tasks.
> >
> > Detailed design document is available in JIRA :
> >
> >
> >
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2Fattachment%2F12991926%2FOzone%2520FS%2520Namespace%2520Proposal%2520v1.0.docx&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xdDl85JUD1Ms2ySzxryuZTe0KH2cXjzarbedOmQ0dxM%3D&reserved=0
> >
> >
> >
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2Fattachment%2F13023399%2FOzoneFS%2520Optimizations_DesignOverview_%2520HDDS-2939.pdf&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402584573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XCO3eWYHwxPl6BbEcW%2BEFtPz8QWrViLBmScaSny6zF0%3D&reserved=0
> >
> > Quick stats on combined HDDS-2939 Patch : Commits
> >
> 8b8a7e3ec84ad14e7128ff5fb3ded542ea9080d7..6d76676d2956346895de630a96c182188f9f3e38
> >
> > 157 files changed, 16289 insertions(+), 776 deletions(-)
> >
> > Added/modified test cases= ~160
> >
> > Thanks a lot to all contributors/reviewers.
> >
> > So, I feel this branch is ready to merge into master branch. Could
> you
> > please provide your feedback. If there are no objections, I will
> proceed
> > for merge voting.
> >
> > Thanks,
> >
> > Rakesh
> >
>
>
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to
master
Posted by Prashant Pogde <pp...@cloudera.com.INVALID>.
+1
-Prashant
> On Apr 5, 2021, at 9:00 AM, Mukul Kumar Singh <mk...@gmail.com> wrote:
>
> +1, This feature will be a great addition to Ozone.
>
> - Mukul
>
> On 05/04/21 8:03 pm, Lin, Yiqun wrote:
>> +1 for merging to master after resolved current few block subtasks. Currently, I see listKey implementation and key deletion lifecycle in FSO hasn't been completed yet.
>>
>> On 2021/4/5, 5:49 PM, "Rakesh Radhakrishnan" <ra...@apache.org> wrote:
>>
>> External Email
>>
>> Hi All,
>>
>> I'm really sorry for the wrong subject line. It is a [DISCUSS] thread and
>> not a VOTE thread.
>>
>> Please excuse me.
>>
>> Thanks,
>> Rakesh
>>
>>
>> On Mon, Apr 5, 2021 at 3:14 PM Rakesh Radhakrishnan <ra...@apache.org>
>> wrote:
>>
>> > Hi All,
>> >
>> > I would like to propose prefix based FileSystem Optimizations (FSO) work
>> > HDDS-2939 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FHDDS-2939&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C1oe4PHLRrGQY9xQ34Zb53JhfRW8tDSKZWOnGe2SNSo%3D&reserved=0> merging into
>> > Ozone master branch. This optimization is intended to support atomic rename
>> > and delete operations in Ozone namespace.
>> >
>> > Presently, a rename/delete operation can become prohibitively expensive
>> > for such directories which have large sub-trees/sub-paths. This
>> > optimization allows to perform rename, delete of any directory in a
>> > deterministic/constant time atomically.
>> >
>> > The main functionality has been implemented and supports o3fs, ofs and
>> > ObjectStore APIs, for details please refer to sub-tasks of HDDS-2939 which
>> > we have been actively working in the feature branch
>> > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fozone%2Ftree%2FHDDS-2939&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kfP%2Fo6LppbkODnzR326CdsIQCtniXrzeVQXflzYTP%2Fo%3D&reserved=0> for the last several
>> > months. There is a configuration to turn this feature ON and OFF while
>> > merging back to master, it will be turned OFF by default for now.
>> >
>> > Merging back to master will greatly help in stabilizing/testing the
>> > feature more rigorously while ensuring the ongoing work on the master
>> > branch is not negatively impacted by the feature as it is turned OFF by
>> > default.
>> >
>> > Following graph compares the performance between master(V0) and new
>> > optimized code(V1) for the delete op in an unsecure cluster. Rename op also
>> > has similar results. Please refer to the attached test report
>> > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2Fattachment%2F13023395%2FPerformance%2BComparison%2BBetween%2B%2BMaster%2Band%2BHDDS-2939%2Bbranch-Report-001.pdf&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s1AvJFVIIglI8ZGW0z11CdkpyQH02zg3Dm8vlDcCsO0%3D&reserved=0>in
>> > jira for more details.
>> >
>> > *Ozone wiki page:*
>> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FOZONE%2FFileSystem%2BOptimizations%2B-%2BHDDS-2939&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KV1SDaXCvHMFmYovH1mqh%2BXcc1QqbvOcVMho9Sq4bOc%3D&reserved=0
>> >
>> > Number of JIRAs Resolved: 27
>> >
>> > Patch Available/WIP: 3 jira
>> >
>> > There are few ongoing sub-tasks, IMHO they are blockers for merge. We will
>> > be actively working on these sub-tasks.
>> >
>> > Detailed design document is available in JIRA :
>> >
>> >
>> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2Fattachment%2F12991926%2FOzone%2520FS%2520Namespace%2520Proposal%2520v1.0.docx&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xdDl85JUD1Ms2ySzxryuZTe0KH2cXjzarbedOmQ0dxM%3D&reserved=0
>> >
>> >
>> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2Fattachment%2F13023399%2FOzoneFS%2520Optimizations_DesignOverview_%2520HDDS-2939.pdf&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402584573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XCO3eWYHwxPl6BbEcW%2BEFtPz8QWrViLBmScaSny6zF0%3D&reserved=0
>> >
>> > Quick stats on combined HDDS-2939 Patch : Commits
>> > 8b8a7e3ec84ad14e7128ff5fb3ded542ea9080d7..6d76676d2956346895de630a96c182188f9f3e38
>> >
>> > 157 files changed, 16289 insertions(+), 776 deletions(-)
>> >
>> > Added/modified test cases= ~160
>> >
>> > Thanks a lot to all contributors/reviewers.
>> >
>> > So, I feel this branch is ready to merge into master branch. Could you
>> > please provide your feedback. If there are no objections, I will proceed
>> > for merge voting.
>> >
>> > Thanks,
>> >
>> > Rakesh
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
>> For additional commands, e-mail: dev-help@ozone.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> For additional commands, e-mail: dev-help@ozone.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to
master
Posted by Mukul Kumar Singh <mk...@gmail.com>.
+1, This feature will be a great addition to Ozone.
- Mukul
On 05/04/21 8:03 pm, Lin, Yiqun wrote:
> +1 for merging to master after resolved current few block subtasks. Currently, I see listKey implementation and key deletion lifecycle in FSO hasn't been completed yet.
>
> On 2021/4/5, 5:49 PM, "Rakesh Radhakrishnan" <ra...@apache.org> wrote:
>
> External Email
>
> Hi All,
>
> I'm really sorry for the wrong subject line. It is a [DISCUSS] thread and
> not a VOTE thread.
>
> Please excuse me.
>
> Thanks,
> Rakesh
>
>
> On Mon, Apr 5, 2021 at 3:14 PM Rakesh Radhakrishnan <ra...@apache.org>
> wrote:
>
> > Hi All,
> >
> > I would like to propose prefix based FileSystem Optimizations (FSO) work
> > HDDS-2939 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FHDDS-2939&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C1oe4PHLRrGQY9xQ34Zb53JhfRW8tDSKZWOnGe2SNSo%3D&reserved=0> merging into
> > Ozone master branch. This optimization is intended to support atomic rename
> > and delete operations in Ozone namespace.
> >
> > Presently, a rename/delete operation can become prohibitively expensive
> > for such directories which have large sub-trees/sub-paths. This
> > optimization allows to perform rename, delete of any directory in a
> > deterministic/constant time atomically.
> >
> > The main functionality has been implemented and supports o3fs, ofs and
> > ObjectStore APIs, for details please refer to sub-tasks of HDDS-2939 which
> > we have been actively working in the feature branch
> > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fozone%2Ftree%2FHDDS-2939&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kfP%2Fo6LppbkODnzR326CdsIQCtniXrzeVQXflzYTP%2Fo%3D&reserved=0> for the last several
> > months. There is a configuration to turn this feature ON and OFF while
> > merging back to master, it will be turned OFF by default for now.
> >
> > Merging back to master will greatly help in stabilizing/testing the
> > feature more rigorously while ensuring the ongoing work on the master
> > branch is not negatively impacted by the feature as it is turned OFF by
> > default.
> >
> > Following graph compares the performance between master(V0) and new
> > optimized code(V1) for the delete op in an unsecure cluster. Rename op also
> > has similar results. Please refer to the attached test report
> > <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2Fattachment%2F13023395%2FPerformance%2BComparison%2BBetween%2B%2BMaster%2Band%2BHDDS-2939%2Bbranch-Report-001.pdf&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s1AvJFVIIglI8ZGW0z11CdkpyQH02zg3Dm8vlDcCsO0%3D&reserved=0>in
> > jira for more details.
> >
> > *Ozone wiki page:*
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FOZONE%2FFileSystem%2BOptimizations%2B-%2BHDDS-2939&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KV1SDaXCvHMFmYovH1mqh%2BXcc1QqbvOcVMho9Sq4bOc%3D&reserved=0
> >
> > Number of JIRAs Resolved: 27
> >
> > Patch Available/WIP: 3 jira
> >
> > There are few ongoing sub-tasks, IMHO they are blockers for merge. We will
> > be actively working on these sub-tasks.
> >
> > Detailed design document is available in JIRA :
> >
> >
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2Fattachment%2F12991926%2FOzone%2520FS%2520Namespace%2520Proposal%2520v1.0.docx&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xdDl85JUD1Ms2ySzxryuZTe0KH2cXjzarbedOmQ0dxM%3D&reserved=0
> >
> >
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2Fattachment%2F13023399%2FOzoneFS%2520Optimizations_DesignOverview_%2520HDDS-2939.pdf&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402584573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XCO3eWYHwxPl6BbEcW%2BEFtPz8QWrViLBmScaSny6zF0%3D&reserved=0
> >
> > Quick stats on combined HDDS-2939 Patch : Commits
> > 8b8a7e3ec84ad14e7128ff5fb3ded542ea9080d7..6d76676d2956346895de630a96c182188f9f3e38
> >
> > 157 files changed, 16289 insertions(+), 776 deletions(-)
> >
> > Added/modified test cases= ~160
> >
> > Thanks a lot to all contributors/reviewers.
> >
> > So, I feel this branch is ready to merge into master branch. Could you
> > please provide your feedback. If there are no objections, I will proceed
> > for merge voting.
> >
> > Thanks,
> >
> > Rakesh
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> For additional commands, e-mail: dev-help@ozone.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to
master
Posted by "Lin, Yiqun" <yi...@ebay.com.INVALID>.
+1 for merging to master after resolved current few block subtasks. Currently, I see listKey implementation and key deletion lifecycle in FSO hasn't been completed yet.
On 2021/4/5, 5:49 PM, "Rakesh Radhakrishnan" <ra...@apache.org> wrote:
External Email
Hi All,
I'm really sorry for the wrong subject line. It is a [DISCUSS] thread and
not a VOTE thread.
Please excuse me.
Thanks,
Rakesh
On Mon, Apr 5, 2021 at 3:14 PM Rakesh Radhakrishnan <ra...@apache.org>
wrote:
> Hi All,
>
> I would like to propose prefix based FileSystem Optimizations (FSO) work
> HDDS-2939 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FHDDS-2939&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C1oe4PHLRrGQY9xQ34Zb53JhfRW8tDSKZWOnGe2SNSo%3D&reserved=0> merging into
> Ozone master branch. This optimization is intended to support atomic rename
> and delete operations in Ozone namespace.
>
> Presently, a rename/delete operation can become prohibitively expensive
> for such directories which have large sub-trees/sub-paths. This
> optimization allows to perform rename, delete of any directory in a
> deterministic/constant time atomically.
>
> The main functionality has been implemented and supports o3fs, ofs and
> ObjectStore APIs, for details please refer to sub-tasks of HDDS-2939 which
> we have been actively working in the feature branch
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fozone%2Ftree%2FHDDS-2939&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kfP%2Fo6LppbkODnzR326CdsIQCtniXrzeVQXflzYTP%2Fo%3D&reserved=0> for the last several
> months. There is a configuration to turn this feature ON and OFF while
> merging back to master, it will be turned OFF by default for now.
>
> Merging back to master will greatly help in stabilizing/testing the
> feature more rigorously while ensuring the ongoing work on the master
> branch is not negatively impacted by the feature as it is turned OFF by
> default.
>
> Following graph compares the performance between master(V0) and new
> optimized code(V1) for the delete op in an unsecure cluster. Rename op also
> has similar results. Please refer to the attached test report
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2Fattachment%2F13023395%2FPerformance%2BComparison%2BBetween%2B%2BMaster%2Band%2BHDDS-2939%2Bbranch-Report-001.pdf&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s1AvJFVIIglI8ZGW0z11CdkpyQH02zg3Dm8vlDcCsO0%3D&reserved=0>in
> jira for more details.
>
> *Ozone wiki page:*
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FOZONE%2FFileSystem%2BOptimizations%2B-%2BHDDS-2939&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KV1SDaXCvHMFmYovH1mqh%2BXcc1QqbvOcVMho9Sq4bOc%3D&reserved=0
>
> Number of JIRAs Resolved: 27
>
> Patch Available/WIP: 3 jira
>
> There are few ongoing sub-tasks, IMHO they are blockers for merge. We will
> be actively working on these sub-tasks.
>
> Detailed design document is available in JIRA :
>
>
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2Fattachment%2F12991926%2FOzone%2520FS%2520Namespace%2520Proposal%2520v1.0.docx&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402574581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xdDl85JUD1Ms2ySzxryuZTe0KH2cXjzarbedOmQ0dxM%3D&reserved=0
>
>
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2Fattachment%2F13023399%2FOzoneFS%2520Optimizations_DesignOverview_%2520HDDS-2939.pdf&data=04%7C01%7Cyiqlin%40ebay.com%7C75c2dc9fdc07443d6af308d8f818089a%7C46326bff992841a0baca17c16c94ea99%7C0%7C1%7C637532129402584573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XCO3eWYHwxPl6BbEcW%2BEFtPz8QWrViLBmScaSny6zF0%3D&reserved=0
>
> Quick stats on combined HDDS-2939 Patch : Commits
> 8b8a7e3ec84ad14e7128ff5fb3ded542ea9080d7..6d76676d2956346895de630a96c182188f9f3e38
>
> 157 files changed, 16289 insertions(+), 776 deletions(-)
>
> Added/modified test cases= ~160
>
> Thanks a lot to all contributors/reviewers.
>
> So, I feel this branch is ready to merge into master branch. Could you
> please provide your feedback. If there are no objections, I will proceed
> for merge voting.
>
> Thanks,
>
> Rakesh
>
[DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to master
Posted by Rakesh Radhakrishnan <ra...@apache.org>.
Hi All,
I'm really sorry for the wrong subject line. It is a [DISCUSS] thread and
not a VOTE thread.
Please excuse me.
Thanks,
Rakesh
On Mon, Apr 5, 2021 at 3:14 PM Rakesh Radhakrishnan <ra...@apache.org>
wrote:
> Hi All,
>
> I would like to propose prefix based FileSystem Optimizations (FSO) work
> HDDS-2939 <https://issues.apache.org/jira/browse/HDDS-2939> merging into
> Ozone master branch. This optimization is intended to support atomic rename
> and delete operations in Ozone namespace.
>
> Presently, a rename/delete operation can become prohibitively expensive
> for such directories which have large sub-trees/sub-paths. This
> optimization allows to perform rename, delete of any directory in a
> deterministic/constant time atomically.
>
> The main functionality has been implemented and supports o3fs, ofs and
> ObjectStore APIs, for details please refer to sub-tasks of HDDS-2939 which
> we have been actively working in the feature branch
> <https://github.com/apache/ozone/tree/HDDS-2939> for the last several
> months. There is a configuration to turn this feature ON and OFF while
> merging back to master, it will be turned OFF by default for now.
>
> Merging back to master will greatly help in stabilizing/testing the
> feature more rigorously while ensuring the ongoing work on the master
> branch is not negatively impacted by the feature as it is turned OFF by
> default.
>
> Following graph compares the performance between master(V0) and new
> optimized code(V1) for the delete op in an unsecure cluster. Rename op also
> has similar results. Please refer to the attached test report
> <https://issues.apache.org/jira/secure/attachment/13023395/Performance+Comparison+Between++Master+and+HDDS-2939+branch-Report-001.pdf>in
> jira for more details.
>
> *Ozone wiki page:*
> https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
>
> Number of JIRAs Resolved: 27
>
> Patch Available/WIP: 3 jira
>
> There are few ongoing sub-tasks, IMHO they are blockers for merge. We will
> be actively working on these sub-tasks.
>
> Detailed design document is available in JIRA :
>
>
> https://issues.apache.org/jira/secure/attachment/12991926/Ozone%20FS%20Namespace%20Proposal%20v1.0.docx
>
>
> https://issues.apache.org/jira/secure/attachment/13023399/OzoneFS%20Optimizations_DesignOverview_%20HDDS-2939.pdf
>
> Quick stats on combined HDDS-2939 Patch : Commits
> 8b8a7e3ec84ad14e7128ff5fb3ded542ea9080d7..6d76676d2956346895de630a96c182188f9f3e38
>
> 157 files changed, 16289 insertions(+), 776 deletions(-)
>
> Added/modified test cases= ~160
>
> Thanks a lot to all contributors/reviewers.
>
> So, I feel this branch is ready to merge into master branch. Could you
> please provide your feedback. If there are no objections, I will proceed
> for merge voting.
>
> Thanks,
>
> Rakesh
>
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to master
Posted by Rakesh Radhakrishnan <ra...@apache.org>.
Hi,
Thanks everyone for the useful feedback, comments and contributions.
All the points/tasks are addressed now and I'm planning to start a vote
thread early next week.
Thanks,
Rakesh
On Tue, May 18, 2021 at 4:08 PM Rakesh Radhakrishnan <ra...@apache.org>
wrote:
> Hi All,
>
> It seems that the "performance comparison chart" mentioned in my previous
> email is not available to others but it's showing it in my sent items. I am
> re-attaching it again with this email, hope it's available to everyone.
> Sorry for multiple emails.
>
> [image: PerfResultChart-KeyCreation-with-diff-layouts.png]
>
> Thanks,
> Rakesh
>
> On Tue, May 18, 2021 at 1:09 PM Rakesh Radhakrishnan <ra...@apache.org>
> wrote:
>
>>
>> Thank you very much @Yiqun for the reply and taking the discussion ahead!
>>
>> Thanks a lot @Marton for the feedback. We were working on the review
>> comments and that caused a delay in my reply.
>>
>> All the points/tasks are addressed and I've updated the wiki page
>> <https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939>as
>> well, please find my reply to the comments and let me know your feedback.
>>
>> > @Marton,
>>
>> > [1] backward compatibility:
>>
>> > No backward compatibility issues. S3 works well as the feature code sits
>>
>> > behind the ozone.om.metadata.layout feature flag. Yes, same
>> normalization
>>
>> > behavior as before. Even with feature turned ON the normalization
>> behaviour
>>
>> > is the same, as the configuration "ozone.om.enable.filesystem.paths"
>> should
>>
>> > be set to "true".
>>
>>
>> >>>> Thanks the answer. It turned out that we have backward compatibility
>>
>> >>>> issues: when the flag is turned on in an existing cluster we can have
>>
>> >>>> unexpected results. One problem is tracked with HDDS-5094, but --- in
>>
>> >>>> general -- I think we should be sure that we have no data
>> inconsistency
>>
>> >>>> loss when feature flag is modified in a cluster. Just to having the
>> flag
>>
>> >>>> doesn't save us from all the backward compatibility issues.
>>
>> >>>> I tested and -- except some backward compatibility issues like
>> HDDS-5094
>>
>> >>>> -- it worked very well
>>
>> Thanks for reporting this case - HDDS-5094. We have fixed it and thanks
>> again for the patch reviews.
>>
>> Also, documented that the new metadata layout feature(prefix) is
>> supported only in a fresh cluster.
>>
>> >
>>
>> > [2] performance:
>>
>> > When it is turned OFF then there is zero performance penalty because the
>>
>> > existing functionality is not changed.
>>
>> >
>>
>> > With the feature flag turned OFF, master code will create intermediate
>>
>> > directories during create. When it is turned ON the prefix code also
>> does a
>>
>> > similar approach during create. But, surely we will be focusing on the
>>
>> > performance path post merge and improving it further.
>>
>> >>>> My question was about the normal key creation performance when the
>> flag
>>
>> >>>> is turned ON. We shared that the deletion / rename performance is
>>
>> >>>> significant better, but I guess we have some overhead in the normal
>> key
>>
>> >>>> creation which would be great to know.
>>
>> Following is the key creation performance comparison chart. When it is
>> turned OFF(simple) then there is zero performance penalty because the
>> current existing functionality is used.
>>
>>
>> >
>>
>> > [4] security:
>>
>> > As you have pointed out, everything works as earlier and there are no
>>
>> > security implications because of the feature.
>>
>> >>>> I just learned that we have new code for all the new key creation
>>
>> >>>> including new ACL checks. So we have new implementation for the
>> existing
>>
>> >>>> functionalities. (I am not sure if we can any test to be more sure,
>> but
>>
>> >>>> it's definitely something which is changed, and -- imho -- even the
>>
>> >>>> alpha features should be secure on master).
>>
>> We have added new test cases to verify prefix + ACLs. Both (prefix) new
>> and (simple) existing test cases are running fine in CI.
>>
>> Also, when the feature is turned OFF the existing code path will work as
>> earlier.
>>
>> >>>> I am just wondering what is the long-term plan here. Do we plan to
>>
>> >>>> handle both prefix/simple code-path with the V1 classes? Or do we
>> plan
>>
>> >>>> to keep both of the classes side by side? Do we plan to avoid
>> duplicated
>>
>> >>>> code, or it's not possible? And what can we do to minimize the new
>>
>> >>>> technical debts?
>>
>> This will be addressed as part of the follow up task HDDS-5232.
>>
>> >>>> While I created HDDS-5106 to use more meaningful names (I don't know
>>
>> >>>> what is V1, is our current master is the V0?) I am still worried
>> about
>>
>> >>>> this coding style.
>>
>> Thanks for the suggestions. We have taken care of this and *V1 classes
>> have been modified to "WithFSO classes. Existing/Original classes are
>> intact.
>>
>>
>> Thanks,
>> Rakesh
>>
>> On Thu, Apr 15, 2021 at 3:26 PM Lin, Yiqun <yi...@ebay.com.invalid>
>> wrote:
>>
>>> > I am just wondering what is the long-term plan here. Do we plan to
>>> handle both prefix/simple code-path with the V1 classes? Or do we
>>> plan
>>> to keep both of the classes side by side? Do we plan to avoid
>>> duplicated
>>> code, or it's not possible? And what can we do to minimize the new
>>> technical debts?
>>> I reviewed most of the feature code during past time. From my personal
>>> opinion, it will increases complexity if we support simple/prefix layout at
>>> the same time under original logic. As prefix layout uses different table
>>> and have the different FS path construction logic. So using a new V1 class
>>> for prefix layout implementation will be a good way to push forward on this
>>> feature. We already reuse some common code loigc during implementation, but
>>> I'm sure there could be more other code lines can be reused. We could have
>>> the further code refactor later I think. Also seems V1 class name looks a
>>> little consused and can be renamed to a more readable name if we don't want
>>> to remove V1 class.
>>>
>>> Thanks,
>>> Yiqun
>>>
>>> On 2021/4/14, 7:35 PM, "Elek, Marton" <el...@apache.org> wrote:
>>>
>>> External Email
>>>
>>>
>>> I strongly recommend for everybody to test the feature and check the
>>> code.
>>>
>>>
>>> I tested and -- except some backward compatibility issues like
>>> HDDS-5094
>>> -- it worked very well.
>>>
>>> I also checked the Java code and I am very surprised by the
>>> implementation. As far as I understand -- but I can be wrong -- both
>>> the
>>> production and test implementation is based on duplicating some
>>> existing
>>> classes with V1 post-fixes with limited code re-usage.
>>>
>>> While I created HDDS-5106 to use more meaningful names (I don't know
>>> what is V1, is our current master is the V0?) I am still worried
>>> about
>>> this coding style.
>>>
>>> I believe that making the code more maintainable is very important
>>> factor (slightly related task about AWS S3 development and
>>> simplicity as
>>> a design choice [1])
>>>
>>> I am just wondering what is the long-term plan here. Do we plan to
>>> handle both prefix/simple code-path with the V1 classes? Or do we
>>> plan
>>> to keep both of the classes side by side? Do we plan to avoid
>>> duplicated
>>> code, or it's not possible? And what can we do to minimize the new
>>> technical debts?
>>>
>>> TLDR; I recommend to everybody to check the code (and test the
>>> branch).
>>>
>>> Thanks,
>>> Marton
>>>
>>>
>>> [1]
>>>
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcacm.acm.org%2Fmagazines%2F2021%2F3%2F250706-a-second-conversation-with-werner-vogels%2Ffulltext&data=04%7C01%7Cyiqlin%40ebay.com%7C7767b46a25be4a660a1508d8ff3974ef%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637539969536472439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NNWShEngcq5VN%2F93yi9uaTP2QsuzHrdN7%2Fn4LMs7L%2FI%3D&reserved=0
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
>>> For additional commands, e-mail: dev-help@ozone.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
>>> For additional commands, e-mail: dev-help@ozone.apache.org
>>>
>>
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to master
Posted by Rakesh Radhakrishnan <ra...@apache.org>.
Hi All,
It seems that the "performance comparison chart" mentioned in my previous
email is not available to others but it's showing it in my sent items. I am
re-attaching it again with this email, hope it's available to everyone.
Sorry for multiple emails.
[image: PerfResultChart-KeyCreation-with-diff-layouts.png]
Thanks,
Rakesh
On Tue, May 18, 2021 at 1:09 PM Rakesh Radhakrishnan <ra...@apache.org>
wrote:
>
> Thank you very much @Yiqun for the reply and taking the discussion ahead!
>
> Thanks a lot @Marton for the feedback. We were working on the review
> comments and that caused a delay in my reply.
>
> All the points/tasks are addressed and I've updated the wiki page
> <https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939>as
> well, please find my reply to the comments and let me know your feedback.
>
> > @Marton,
>
> > [1] backward compatibility:
>
> > No backward compatibility issues. S3 works well as the feature code sits
>
> > behind the ozone.om.metadata.layout feature flag. Yes, same normalization
>
> > behavior as before. Even with feature turned ON the normalization
> behaviour
>
> > is the same, as the configuration "ozone.om.enable.filesystem.paths"
> should
>
> > be set to "true".
>
>
> >>>> Thanks the answer. It turned out that we have backward compatibility
>
> >>>> issues: when the flag is turned on in an existing cluster we can have
>
> >>>> unexpected results. One problem is tracked with HDDS-5094, but --- in
>
> >>>> general -- I think we should be sure that we have no data
> inconsistency
>
> >>>> loss when feature flag is modified in a cluster. Just to having the
> flag
>
> >>>> doesn't save us from all the backward compatibility issues.
>
> >>>> I tested and -- except some backward compatibility issues like
> HDDS-5094
>
> >>>> -- it worked very well
>
> Thanks for reporting this case - HDDS-5094. We have fixed it and thanks
> again for the patch reviews.
>
> Also, documented that the new metadata layout feature(prefix) is
> supported only in a fresh cluster.
>
> >
>
> > [2] performance:
>
> > When it is turned OFF then there is zero performance penalty because the
>
> > existing functionality is not changed.
>
> >
>
> > With the feature flag turned OFF, master code will create intermediate
>
> > directories during create. When it is turned ON the prefix code also
> does a
>
> > similar approach during create. But, surely we will be focusing on the
>
> > performance path post merge and improving it further.
>
> >>>> My question was about the normal key creation performance when the
> flag
>
> >>>> is turned ON. We shared that the deletion / rename performance is
>
> >>>> significant better, but I guess we have some overhead in the normal
> key
>
> >>>> creation which would be great to know.
>
> Following is the key creation performance comparison chart. When it is
> turned OFF(simple) then there is zero performance penalty because the
> current existing functionality is used.
>
>
> >
>
> > [4] security:
>
> > As you have pointed out, everything works as earlier and there are no
>
> > security implications because of the feature.
>
> >>>> I just learned that we have new code for all the new key creation
>
> >>>> including new ACL checks. So we have new implementation for the
> existing
>
> >>>> functionalities. (I am not sure if we can any test to be more sure,
> but
>
> >>>> it's definitely something which is changed, and -- imho -- even the
>
> >>>> alpha features should be secure on master).
>
> We have added new test cases to verify prefix + ACLs. Both (prefix) new
> and (simple) existing test cases are running fine in CI.
>
> Also, when the feature is turned OFF the existing code path will work as
> earlier.
>
> >>>> I am just wondering what is the long-term plan here. Do we plan to
>
> >>>> handle both prefix/simple code-path with the V1 classes? Or do we plan
>
> >>>> to keep both of the classes side by side? Do we plan to avoid
> duplicated
>
> >>>> code, or it's not possible? And what can we do to minimize the new
>
> >>>> technical debts?
>
> This will be addressed as part of the follow up task HDDS-5232.
>
> >>>> While I created HDDS-5106 to use more meaningful names (I don't know
>
> >>>> what is V1, is our current master is the V0?) I am still worried about
>
> >>>> this coding style.
>
> Thanks for the suggestions. We have taken care of this and *V1 classes
> have been modified to "WithFSO classes. Existing/Original classes are
> intact.
>
>
> Thanks,
> Rakesh
>
> On Thu, Apr 15, 2021 at 3:26 PM Lin, Yiqun <yi...@ebay.com.invalid>
> wrote:
>
>> > I am just wondering what is the long-term plan here. Do we plan to
>> handle both prefix/simple code-path with the V1 classes? Or do we
>> plan
>> to keep both of the classes side by side? Do we plan to avoid
>> duplicated
>> code, or it's not possible? And what can we do to minimize the new
>> technical debts?
>> I reviewed most of the feature code during past time. From my personal
>> opinion, it will increases complexity if we support simple/prefix layout at
>> the same time under original logic. As prefix layout uses different table
>> and have the different FS path construction logic. So using a new V1 class
>> for prefix layout implementation will be a good way to push forward on this
>> feature. We already reuse some common code loigc during implementation, but
>> I'm sure there could be more other code lines can be reused. We could have
>> the further code refactor later I think. Also seems V1 class name looks a
>> little consused and can be renamed to a more readable name if we don't want
>> to remove V1 class.
>>
>> Thanks,
>> Yiqun
>>
>> On 2021/4/14, 7:35 PM, "Elek, Marton" <el...@apache.org> wrote:
>>
>> External Email
>>
>>
>> I strongly recommend for everybody to test the feature and check the
>> code.
>>
>>
>> I tested and -- except some backward compatibility issues like
>> HDDS-5094
>> -- it worked very well.
>>
>> I also checked the Java code and I am very surprised by the
>> implementation. As far as I understand -- but I can be wrong -- both
>> the
>> production and test implementation is based on duplicating some
>> existing
>> classes with V1 post-fixes with limited code re-usage.
>>
>> While I created HDDS-5106 to use more meaningful names (I don't know
>> what is V1, is our current master is the V0?) I am still worried
>> about
>> this coding style.
>>
>> I believe that making the code more maintainable is very important
>> factor (slightly related task about AWS S3 development and simplicity
>> as
>> a design choice [1])
>>
>> I am just wondering what is the long-term plan here. Do we plan to
>> handle both prefix/simple code-path with the V1 classes? Or do we
>> plan
>> to keep both of the classes side by side? Do we plan to avoid
>> duplicated
>> code, or it's not possible? And what can we do to minimize the new
>> technical debts?
>>
>> TLDR; I recommend to everybody to check the code (and test the
>> branch).
>>
>> Thanks,
>> Marton
>>
>>
>> [1]
>>
>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcacm.acm.org%2Fmagazines%2F2021%2F3%2F250706-a-second-conversation-with-werner-vogels%2Ffulltext&data=04%7C01%7Cyiqlin%40ebay.com%7C7767b46a25be4a660a1508d8ff3974ef%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637539969536472439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NNWShEngcq5VN%2F93yi9uaTP2QsuzHrdN7%2Fn4LMs7L%2FI%3D&reserved=0
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
>> For additional commands, e-mail: dev-help@ozone.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
>> For additional commands, e-mail: dev-help@ozone.apache.org
>>
>
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to master
Posted by Rakesh Radhakrishnan <ra...@apache.org>.
Thank you very much @Yiqun for the reply and taking the discussion ahead!
Thanks a lot @Marton for the feedback. We were working on the review
comments and that caused a delay in my reply.
All the points/tasks are addressed and I've updated the wiki page
<https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939>as
well, please find my reply to the comments and let me know your feedback.
> @Marton,
> [1] backward compatibility:
> No backward compatibility issues. S3 works well as the feature code sits
> behind the ozone.om.metadata.layout feature flag. Yes, same normalization
> behavior as before. Even with feature turned ON the normalization
behaviour
> is the same, as the configuration "ozone.om.enable.filesystem.paths"
should
> be set to "true".
>>>> Thanks the answer. It turned out that we have backward compatibility
>>>> issues: when the flag is turned on in an existing cluster we can have
>>>> unexpected results. One problem is tracked with HDDS-5094, but --- in
>>>> general -- I think we should be sure that we have no data inconsistency
>>>> loss when feature flag is modified in a cluster. Just to having the
flag
>>>> doesn't save us from all the backward compatibility issues.
>>>> I tested and -- except some backward compatibility issues like
HDDS-5094
>>>> -- it worked very well
Thanks for reporting this case - HDDS-5094. We have fixed it and thanks
again for the patch reviews.
Also, documented that the new metadata layout feature(prefix) is supported
only in a fresh cluster.
>
> [2] performance:
> When it is turned OFF then there is zero performance penalty because the
> existing functionality is not changed.
>
> With the feature flag turned OFF, master code will create intermediate
> directories during create. When it is turned ON the prefix code also does
a
> similar approach during create. But, surely we will be focusing on the
> performance path post merge and improving it further.
>>>> My question was about the normal key creation performance when the flag
>>>> is turned ON. We shared that the deletion / rename performance is
>>>> significant better, but I guess we have some overhead in the normal key
>>>> creation which would be great to know.
Following is the key creation performance comparison chart. When it is
turned OFF(simple) then there is zero performance penalty because the
current existing functionality is used.
>
> [4] security:
> As you have pointed out, everything works as earlier and there are no
> security implications because of the feature.
>>>> I just learned that we have new code for all the new key creation
>>>> including new ACL checks. So we have new implementation for the
existing
>>>> functionalities. (I am not sure if we can any test to be more sure, but
>>>> it's definitely something which is changed, and -- imho -- even the
>>>> alpha features should be secure on master).
We have added new test cases to verify prefix + ACLs. Both (prefix) new and
(simple) existing test cases are running fine in CI.
Also, when the feature is turned OFF the existing code path will work as
earlier.
>>>> I am just wondering what is the long-term plan here. Do we plan to
>>>> handle both prefix/simple code-path with the V1 classes? Or do we plan
>>>> to keep both of the classes side by side? Do we plan to avoid
duplicated
>>>> code, or it's not possible? And what can we do to minimize the new
>>>> technical debts?
This will be addressed as part of the follow up task HDDS-5232.
>>>> While I created HDDS-5106 to use more meaningful names (I don't know
>>>> what is V1, is our current master is the V0?) I am still worried about
>>>> this coding style.
Thanks for the suggestions. We have taken care of this and *V1 classes have
been modified to "WithFSO classes. Existing/Original classes are intact.
Thanks,
Rakesh
On Thu, Apr 15, 2021 at 3:26 PM Lin, Yiqun <yi...@ebay.com.invalid> wrote:
> > I am just wondering what is the long-term plan here. Do we plan to
> handle both prefix/simple code-path with the V1 classes? Or do we plan
> to keep both of the classes side by side? Do we plan to avoid
> duplicated
> code, or it's not possible? And what can we do to minimize the new
> technical debts?
> I reviewed most of the feature code during past time. From my personal
> opinion, it will increases complexity if we support simple/prefix layout at
> the same time under original logic. As prefix layout uses different table
> and have the different FS path construction logic. So using a new V1 class
> for prefix layout implementation will be a good way to push forward on this
> feature. We already reuse some common code loigc during implementation, but
> I'm sure there could be more other code lines can be reused. We could have
> the further code refactor later I think. Also seems V1 class name looks a
> little consused and can be renamed to a more readable name if we don't want
> to remove V1 class.
>
> Thanks,
> Yiqun
>
> On 2021/4/14, 7:35 PM, "Elek, Marton" <el...@apache.org> wrote:
>
> External Email
>
>
> I strongly recommend for everybody to test the feature and check the
> code.
>
>
> I tested and -- except some backward compatibility issues like
> HDDS-5094
> -- it worked very well.
>
> I also checked the Java code and I am very surprised by the
> implementation. As far as I understand -- but I can be wrong -- both
> the
> production and test implementation is based on duplicating some
> existing
> classes with V1 post-fixes with limited code re-usage.
>
> While I created HDDS-5106 to use more meaningful names (I don't know
> what is V1, is our current master is the V0?) I am still worried about
> this coding style.
>
> I believe that making the code more maintainable is very important
> factor (slightly related task about AWS S3 development and simplicity
> as
> a design choice [1])
>
> I am just wondering what is the long-term plan here. Do we plan to
> handle both prefix/simple code-path with the V1 classes? Or do we plan
> to keep both of the classes side by side? Do we plan to avoid
> duplicated
> code, or it's not possible? And what can we do to minimize the new
> technical debts?
>
> TLDR; I recommend to everybody to check the code (and test the branch).
>
> Thanks,
> Marton
>
>
> [1]
>
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcacm.acm.org%2Fmagazines%2F2021%2F3%2F250706-a-second-conversation-with-werner-vogels%2Ffulltext&data=04%7C01%7Cyiqlin%40ebay.com%7C7767b46a25be4a660a1508d8ff3974ef%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637539969536472439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NNWShEngcq5VN%2F93yi9uaTP2QsuzHrdN7%2Fn4LMs7L%2FI%3D&reserved=0
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> For additional commands, e-mail: dev-help@ozone.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> For additional commands, e-mail: dev-help@ozone.apache.org
>
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to
master
Posted by "Lin, Yiqun" <yi...@ebay.com.INVALID>.
> I am just wondering what is the long-term plan here. Do we plan to
handle both prefix/simple code-path with the V1 classes? Or do we plan
to keep both of the classes side by side? Do we plan to avoid duplicated
code, or it's not possible? And what can we do to minimize the new
technical debts?
I reviewed most of the feature code during past time. From my personal opinion, it will increases complexity if we support simple/prefix layout at the same time under original logic. As prefix layout uses different table and have the different FS path construction logic. So using a new V1 class for prefix layout implementation will be a good way to push forward on this feature. We already reuse some common code loigc during implementation, but I'm sure there could be more other code lines can be reused. We could have the further code refactor later I think. Also seems V1 class name looks a little consused and can be renamed to a more readable name if we don't want to remove V1 class.
Thanks,
Yiqun
On 2021/4/14, 7:35 PM, "Elek, Marton" <el...@apache.org> wrote:
External Email
I strongly recommend for everybody to test the feature and check the code.
I tested and -- except some backward compatibility issues like HDDS-5094
-- it worked very well.
I also checked the Java code and I am very surprised by the
implementation. As far as I understand -- but I can be wrong -- both the
production and test implementation is based on duplicating some existing
classes with V1 post-fixes with limited code re-usage.
While I created HDDS-5106 to use more meaningful names (I don't know
what is V1, is our current master is the V0?) I am still worried about
this coding style.
I believe that making the code more maintainable is very important
factor (slightly related task about AWS S3 development and simplicity as
a design choice [1])
I am just wondering what is the long-term plan here. Do we plan to
handle both prefix/simple code-path with the V1 classes? Or do we plan
to keep both of the classes side by side? Do we plan to avoid duplicated
code, or it's not possible? And what can we do to minimize the new
technical debts?
TLDR; I recommend to everybody to check the code (and test the branch).
Thanks,
Marton
[1]
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcacm.acm.org%2Fmagazines%2F2021%2F3%2F250706-a-second-conversation-with-werner-vogels%2Ffulltext&data=04%7C01%7Cyiqlin%40ebay.com%7C7767b46a25be4a660a1508d8ff3974ef%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C637539969536472439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NNWShEngcq5VN%2F93yi9uaTP2QsuzHrdN7%2Fn4LMs7L%2FI%3D&reserved=0
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to
master
Posted by "Elek, Marton" <el...@apache.org>.
I strongly recommend for everybody to test the feature and check the code.
I tested and -- except some backward compatibility issues like HDDS-5094
-- it worked very well.
I also checked the Java code and I am very surprised by the
implementation. As far as I understand -- but I can be wrong -- both the
production and test implementation is based on duplicating some existing
classes with V1 post-fixes with limited code re-usage.
While I created HDDS-5106 to use more meaningful names (I don't know
what is V1, is our current master is the V0?) I am still worried about
this coding style.
I believe that making the code more maintainable is very important
factor (slightly related task about AWS S3 development and simplicity as
a design choice [1])
I am just wondering what is the long-term plan here. Do we plan to
handle both prefix/simple code-path with the V1 classes? Or do we plan
to keep both of the classes side by side? Do we plan to avoid duplicated
code, or it's not possible? And what can we do to minimize the new
technical debts?
TLDR; I recommend to everybody to check the code (and test the branch).
Thanks,
Marton
[1]
https://cacm.acm.org/magazines/2021/3/250706-a-second-conversation-with-werner-vogels/fulltext
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to
master
Posted by "Elek, Marton" <el...@apache.org>.
> @Marton,
> [1] backward compatibility:
> No backward compatibility issues. S3 works well as the feature code sits
> behind the ozone.om.metadata.layout feature flag. Yes, same normalization
> behavior as before. Even with feature turned ON the normalization behaviour
> is the same, as the configuration "ozone.om.enable.filesystem.paths" should
> be set to "true".
Thanks the answer. It turned out that we have backward compatibility
issues: when the flag is turned on in an existing cluster we can have
unexpected results. One problem is tracked with HDDS-5094, but --- in
general -- I think we should be sure that we have no data inconsistency
loss when feature flag is modified in a cluster. Just to having the flag
doesn't save us from all the backward compatibility issues.
>
> [2] performance:
> When it is turned OFF then there is zero performance penalty because the
> existing functionality is not changed.
>
> With the feature flag turned OFF, master code will create intermediate
> directories during create. When it is turned ON the prefix code also does a
> similar approach during create. But, surely we will be focusing on the
> performance path post merge and improving it further.
My question was about the normal key creation performance when the flag
is turned ON. We shared that the deletion / rename performance is
significant better, but I guess we have some overhead in the normal key
creation which would be great to know.
>
> [4] security:
> As you have pointed out, everything works as earlier and there are no
> security implications because of the feature.
I just learned that we have new code for all the new key creation
including new ACL checks. So we have new implementation for the existing
functionalities. (I am not sure if we can any test to be more sure, but
it's definitely something which is changed, and -- imho -- even the
alpha features should be secure on master).
Thanks the answers,
Marton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to
master
Posted by Lokesh Jain <lj...@apache.org>.
Thanks for working on this feature!
+1
Regards
Lokesh
> On 08-Apr-2021, at 11:05 PM, Rakesh Radhakrishnan <ra...@apache.org> wrote:
>
> Thank you very much Yiqun and Marton for the feedback/useful comments.
> Please find my responses below.
>
> @Yiqun,
> As per the discussions, key deletion tasks have been implemented and the
> basic functionality of #listKeys works as expected and will be improving it
> further after merging the feature to master branch. Also, I've created a
> follow-up umbrella jira for further optimizations/improvement tasks.
>
> @Marton,
> [1] backward compatibility:
> No backward compatibility issues. S3 works well as the feature code sits
> behind the ozone.om.metadata.layout feature flag. Yes, same normalization
> behavior as before. Even with feature turned ON the normalization behaviour
> is the same, as the configuration "ozone.om.enable.filesystem.paths" should
> be set to "true".
>
> [2] performance:
> When it is turned OFF then there is zero performance penalty because the
> existing functionality is not changed.
>
> With the feature flag turned OFF, master code will create intermediate
> directories during create. When it is turned ON the prefix code also does a
> similar approach during create. But, surely we will be focusing on the
> performance path post merge and improving it further.
>
> [3] documentation:
>
> Done. HDDS-5067. Thank you for the useful review comments.
>
> [4] security:
> As you have pointed out, everything works as earlier and there are no
> security implications because of the feature.
>
> [5] branch merging" checklist:
> I've updated the feature merge wiki page
> <https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939>.
> Thanks!
>
> [6] >>> I assume you planned to write "not blockers" in the first line
> I’m really sorry for the typo. Yes, "those are not blockers for the merge".
> All the in progress tasks have been implemented now.
>
> [7] >>> We can communicate that the feature is still in alpha phase
>
> Yes, we have covered the basic functionalities and #listKeys basic part
> works fine. We have added unit test cases and acceptance test cases to
> ensure stability and will be actively working to improve it further after
> the merge.
>
> The feature is disabled by default and won’t affect the stability of the
> master branch code.
>
>
>
> @Yiqun, @Marton
> Welcome suggestions/feedback. Thanks again for your time and your
> suggestions in shaping up this feature :-)
>
> Thanks,
> Rakesh
>
> On Tue, Apr 6, 2021 at 2:05 PM Elek, Marton <el...@apache.org> wrote:
>
>>
>> Thank you very much to start the discussion Rakesh (and thanks to work
>> on this.)
>>
>> As this is something which can greatly improve the performance for the
>> FS use-cases, I am really exited.
>>
>> To make sure that we can guarantee the stability of the master branch, I
>> would recommend to fill the "branch merging" checklist:
>>
>> https://cwiki.apache.org/confluence/display/OZONE/Merging+branches
>>
>> It would also provide additional information for all the contributors
>> who would prefer to test this feature before/during the vote.
>>
>> I am especially interested about:
>>
>> 1. backward compatibility: if I understand well, it's an optional
>> feature, so we can use s3 interface as before. But what about if we turn
>> this feature off, what can we expect from the s3 interface? Do we have
>> exactly the same normalization behavior as before or it's changed (I
>> have no problem with any way, as it can be turned on and off, but curious).
>>
>> 2. performance: this is already shared on the wiki page, and it's
>> awesome. One minor question: as far as I understood we have slightly
>> more overhead on the normal path (we should update / query multiple
>> rocksdb tables). I don't assume significant slowness there, but do we
>> have any measurements / numbers related to normal key creation vs master?
>>
>> 3. documentation: It would be great to have at least a basic level
>> documentation as part of 'hadoop-hdds/docs'. It would help us to further
>> test it in different environments.
>>
>> 4. security: I am interested if there are any security implication of
>> security checks are modified (I assume everything works as before, but
>> would be great to have confirmation / more information)
>>
>>
>>
>>> *Ozone wiki page:*
>>
>>>
>>
>> https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
>>
>>
>> Thanks to share all these information. I found that some of the
>> sub-pages have confusing URLs:
>>
>> https://cwiki.apache.org/confluence/display/OZONE/Configurations
>> https://cwiki.apache.org/confluence/display/OZONE/Documents
>>
>> These pages are related to the branch but URL may suggest that these are
>> generic, Ozone related information.
>>
>> To fix this, I merged all the subpages to one page and moved the page
>> under the "Merging branch subsection" to have a consistent structure.
>>
>>
>>
>>> There are few ongoing sub-tasks, IMHO they are blockers for merge.
>>
>>> So, I feel this branch is ready to merge into master branch.
>>
>>
>> I am not sure if I understand these two sentences together, I assume you
>> planned to write "not blockers" in the first line (two lines seems to
>> have opposite meaning without this assumption).
>>
>> Let me add some related thoughts: There are two implications/risks of
>> merging something to the master:
>>
>> 1. Master can become more unstable
>> 2. Master will be delivered in the next release to the users
>>
>>
>> 1. seems to be fine, as it can be turned off, the risk is low, and we
>> can further decrease it with double-checking the stability based on the
>> mentioned checklist.
>>
>> Second is more interesting and I am really interested about your
>> opinions: if we have a new feature on master, it will be part of the new
>> release. If the feature is not functional-ready, yet (eg. list keys are
>> not working, yet), users who turn it on may be confused, as instead of a
>> new (alpha-) feature they may get an inconsistent / faulty (?) behavior.
>>
>> We can communicate that the feature is still in alpha phase, but we need
>> some level of functional completeness (IMHO).
>>
>> As an example: SCM-HA is merged with completeness of security
>> implementation, but SCM-HA raft ring for non-secure clusters can be
>> started to test and functional complete. And we clearly communicate that
>> security can not be used (yet).
>>
>> What do you think?
>>
>>
>>
>> Thanks again to start this discussion, (and if any help is required for
>> the merge related to build / ci / testing, I would be happy to help /
>> support it)
>>
>> Marton
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
>> For additional commands, e-mail: dev-help@ozone.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to master
Posted by Aravindan Vijayan <av...@cloudera.com.INVALID>.
+1 to merging this feature.
Rakesh, I will work with you to onboard this onto upgrades, which is also
close to merge.
On Fri, Apr 9, 2021 at 8:35 AM Ayush Saxena <ay...@gmail.com> wrote:
> Thanx Rakesh for driving this.
> Quickly tried some basic stuff with this. Looks good.
>
> +1, Good Luck!!!
>
> -Ayush
>
> > On 09-Apr-2021, at 2:15 PM, Shashikant Banerjee <sb...@cloudera.com.invalid>
> wrote:
> > +1
> >
> > Thanks
> > Shashi
> >
> >> On Fri, Apr 9, 2021 at 1:39 PM Sadanand Shenoy <
> >> sadanand.shenoy4898@gmail.com> wrote:
> >> +1, Thanks for working on this feature.
> >> Regards,
> >> Sadanand
> >> On Thu, Apr 8, 2021, 11:05 PM Rakesh Radhakrishnan <ra...@apache.org>
> >> wrote:
> >>> Thank you very much Yiqun and Marton for the feedback/useful comments.
> >>> Please find my responses below.
> >>> @Yiqun,
> >>> As per the discussions, key deletion tasks have been implemented and
> the
> >>> basic functionality of #listKeys works as expected and will be
> improving
> >> it
> >>> further after merging the feature to master branch. Also, I've created
> a
> >>> follow-up umbrella jira for further optimizations/improvement tasks.
> >>> @Marton,
> >>> [1] backward compatibility:
> >>> No backward compatibility issues. S3 works well as the feature code
> sits
> >>> behind the ozone.om.metadata.layout feature flag. Yes, same
> normalization
> >>> behavior as before. Even with feature turned ON the normalization
> >> behaviour
> >>> is the same, as the configuration "ozone.om.enable.filesystem.paths"
> >> should
> >>> be set to "true".
> >>> [2] performance:
> >>> When it is turned OFF then there is zero performance penalty because
> the
> >>> existing functionality is not changed.
> >>> With the feature flag turned OFF, master code will create intermediate
> >>> directories during create. When it is turned ON the prefix code also
> >> does a
> >>> similar approach during create. But, surely we will be focusing on the
> >>> performance path post merge and improving it further.
> >>> [3] documentation:
> >>> Done. HDDS-5067. Thank you for the useful review comments.
> >>> [4] security:
> >>> As you have pointed out, everything works as earlier and there are no
> >>> security implications because of the feature.
> >>> [5] branch merging" checklist:
> >>> I've updated the feature merge wiki page
> >>> <
> >>
> https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
> >>>> .
> >>> Thanks!
> >>> [6] >>> I assume you planned to write "not blockers" in the first line
> >>> I’m really sorry for the typo. Yes, "those are not blockers for the
> >> merge".
> >>> All the in progress tasks have been implemented now.
> >>> [7] >>> We can communicate that the feature is still in alpha phase
> >>> Yes, we have covered the basic functionalities and #listKeys basic part
> >>> works fine. We have added unit test cases and acceptance test cases to
> >>> ensure stability and will be actively working to improve it further
> after
> >>> the merge.
> >>> The feature is disabled by default and won’t affect the stability of
> the
> >>> master branch code.
> >>> @Yiqun, @Marton
> >>> Welcome suggestions/feedback. Thanks again for your time and your
> >>> suggestions in shaping up this feature :-)
> >>> Thanks,
> >>> Rakesh
> >>>> On Tue, Apr 6, 2021 at 2:05 PM Elek, Marton <el...@apache.org> wrote:
> >>>> Thank you very much to start the discussion Rakesh (and thanks to work
> >>>> on this.)
> >>>> As this is something which can greatly improve the performance for the
> >>>> FS use-cases, I am really exited.
> >>>> To make sure that we can guarantee the stability of the master branch,
> >> I
> >>>> would recommend to fill the "branch merging" checklist:
> >>>> https://cwiki.apache.org/confluence/display/OZONE/Merging+branches
> >>>> It would also provide additional information for all the contributors
> >>>> who would prefer to test this feature before/during the vote.
> >>>> I am especially interested about:
> >>>> 1. backward compatibility: if I understand well, it's an optional
> >>>> feature, so we can use s3 interface as before. But what about if we
> >> turn
> >>>> this feature off, what can we expect from the s3 interface? Do we have
> >>>> exactly the same normalization behavior as before or it's changed (I
> >>>> have no problem with any way, as it can be turned on and off, but
> >>> curious).
> >>>> 2. performance: this is already shared on the wiki page, and it's
> >>>> awesome. One minor question: as far as I understood we have slightly
> >>>> more overhead on the normal path (we should update / query multiple
> >>>> rocksdb tables). I don't assume significant slowness there, but do we
> >>>> have any measurements / numbers related to normal key creation vs
> >> master?
> >>>> 3. documentation: It would be great to have at least a basic level
> >>>> documentation as part of 'hadoop-hdds/docs'. It would help us to
> >> further
> >>>> test it in different environments.
> >>>> 4. security: I am interested if there are any security implication of
> >>>> security checks are modified (I assume everything works as before, but
> >>>> would be great to have confirmation / more information)
> >>>>> *Ozone wiki page:*
> >>
> https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
> >>>> Thanks to share all these information. I found that some of the
> >>>> sub-pages have confusing URLs:
> >>>> https://cwiki.apache.org/confluence/display/OZONE/Configurations
> >>>> https://cwiki.apache.org/confluence/display/OZONE/Documents
> >>>> These pages are related to the branch but URL may suggest that these
> >> are
> >>>> generic, Ozone related information.
> >>>> To fix this, I merged all the subpages to one page and moved the page
> >>>> under the "Merging branch subsection" to have a consistent structure.
> >>>>> There are few ongoing sub-tasks, IMHO they are blockers for merge.
> >>>>> So, I feel this branch is ready to merge into master branch.
> >>>> I am not sure if I understand these two sentences together, I assume
> >> you
> >>>> planned to write "not blockers" in the first line (two lines seems to
> >>>> have opposite meaning without this assumption).
> >>>> Let me add some related thoughts: There are two implications/risks of
> >>>> merging something to the master:
> >>>> 1. Master can become more unstable
> >>>> 2. Master will be delivered in the next release to the users
> >>>> 1. seems to be fine, as it can be turned off, the risk is low, and we
> >>>> can further decrease it with double-checking the stability based on
> the
> >>>> mentioned checklist.
> >>>> Second is more interesting and I am really interested about your
> >>>> opinions: if we have a new feature on master, it will be part of the
> >> new
> >>>> release. If the feature is not functional-ready, yet (eg. list keys
> are
> >>>> not working, yet), users who turn it on may be confused, as instead of
> >> a
> >>>> new (alpha-) feature they may get an inconsistent / faulty (?)
> >> behavior.
> >>>> We can communicate that the feature is still in alpha phase, but we
> >> need
> >>>> some level of functional completeness (IMHO).
> >>>> As an example: SCM-HA is merged with completeness of security
> >>>> implementation, but SCM-HA raft ring for non-secure clusters can be
> >>>> started to test and functional complete. And we clearly communicate
> >> that
> >>>> security can not be used (yet).
> >>>> What do you think?
> >>>> Thanks again to start this discussion, (and if any help is required
> for
> >>>> the merge related to build / ci / testing, I would be happy to help /
> >>>> support it)
> >>>> Marton
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> >>>> For additional commands, e-mail: dev-help@ozone.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> For additional commands, e-mail: dev-help@ozone.apache.org
>
>
--
Thanks & Regards,
Aravindan
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to master
Posted by Ayush Saxena <ay...@gmail.com>.
Thanx Rakesh for driving this.
Quickly tried some basic stuff with this. Looks good.
+1, Good Luck!!!
-Ayush
> On 09-Apr-2021, at 2:15 PM, Shashikant Banerjee <sb...@cloudera.com.invalid> wrote:
> +1
>
> Thanks
> Shashi
>
>> On Fri, Apr 9, 2021 at 1:39 PM Sadanand Shenoy <
>> sadanand.shenoy4898@gmail.com> wrote:
>> +1, Thanks for working on this feature.
>> Regards,
>> Sadanand
>> On Thu, Apr 8, 2021, 11:05 PM Rakesh Radhakrishnan <ra...@apache.org>
>> wrote:
>>> Thank you very much Yiqun and Marton for the feedback/useful comments.
>>> Please find my responses below.
>>> @Yiqun,
>>> As per the discussions, key deletion tasks have been implemented and the
>>> basic functionality of #listKeys works as expected and will be improving
>> it
>>> further after merging the feature to master branch. Also, I've created a
>>> follow-up umbrella jira for further optimizations/improvement tasks.
>>> @Marton,
>>> [1] backward compatibility:
>>> No backward compatibility issues. S3 works well as the feature code sits
>>> behind the ozone.om.metadata.layout feature flag. Yes, same normalization
>>> behavior as before. Even with feature turned ON the normalization
>> behaviour
>>> is the same, as the configuration "ozone.om.enable.filesystem.paths"
>> should
>>> be set to "true".
>>> [2] performance:
>>> When it is turned OFF then there is zero performance penalty because the
>>> existing functionality is not changed.
>>> With the feature flag turned OFF, master code will create intermediate
>>> directories during create. When it is turned ON the prefix code also
>> does a
>>> similar approach during create. But, surely we will be focusing on the
>>> performance path post merge and improving it further.
>>> [3] documentation:
>>> Done. HDDS-5067. Thank you for the useful review comments.
>>> [4] security:
>>> As you have pointed out, everything works as earlier and there are no
>>> security implications because of the feature.
>>> [5] branch merging" checklist:
>>> I've updated the feature merge wiki page
>>> <
>> https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
>>>> .
>>> Thanks!
>>> [6] >>> I assume you planned to write "not blockers" in the first line
>>> I’m really sorry for the typo. Yes, "those are not blockers for the
>> merge".
>>> All the in progress tasks have been implemented now.
>>> [7] >>> We can communicate that the feature is still in alpha phase
>>> Yes, we have covered the basic functionalities and #listKeys basic part
>>> works fine. We have added unit test cases and acceptance test cases to
>>> ensure stability and will be actively working to improve it further after
>>> the merge.
>>> The feature is disabled by default and won’t affect the stability of the
>>> master branch code.
>>> @Yiqun, @Marton
>>> Welcome suggestions/feedback. Thanks again for your time and your
>>> suggestions in shaping up this feature :-)
>>> Thanks,
>>> Rakesh
>>>> On Tue, Apr 6, 2021 at 2:05 PM Elek, Marton <el...@apache.org> wrote:
>>>> Thank you very much to start the discussion Rakesh (and thanks to work
>>>> on this.)
>>>> As this is something which can greatly improve the performance for the
>>>> FS use-cases, I am really exited.
>>>> To make sure that we can guarantee the stability of the master branch,
>> I
>>>> would recommend to fill the "branch merging" checklist:
>>>> https://cwiki.apache.org/confluence/display/OZONE/Merging+branches
>>>> It would also provide additional information for all the contributors
>>>> who would prefer to test this feature before/during the vote.
>>>> I am especially interested about:
>>>> 1. backward compatibility: if I understand well, it's an optional
>>>> feature, so we can use s3 interface as before. But what about if we
>> turn
>>>> this feature off, what can we expect from the s3 interface? Do we have
>>>> exactly the same normalization behavior as before or it's changed (I
>>>> have no problem with any way, as it can be turned on and off, but
>>> curious).
>>>> 2. performance: this is already shared on the wiki page, and it's
>>>> awesome. One minor question: as far as I understood we have slightly
>>>> more overhead on the normal path (we should update / query multiple
>>>> rocksdb tables). I don't assume significant slowness there, but do we
>>>> have any measurements / numbers related to normal key creation vs
>> master?
>>>> 3. documentation: It would be great to have at least a basic level
>>>> documentation as part of 'hadoop-hdds/docs'. It would help us to
>> further
>>>> test it in different environments.
>>>> 4. security: I am interested if there are any security implication of
>>>> security checks are modified (I assume everything works as before, but
>>>> would be great to have confirmation / more information)
>>>>> *Ozone wiki page:*
>> https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
>>>> Thanks to share all these information. I found that some of the
>>>> sub-pages have confusing URLs:
>>>> https://cwiki.apache.org/confluence/display/OZONE/Configurations
>>>> https://cwiki.apache.org/confluence/display/OZONE/Documents
>>>> These pages are related to the branch but URL may suggest that these
>> are
>>>> generic, Ozone related information.
>>>> To fix this, I merged all the subpages to one page and moved the page
>>>> under the "Merging branch subsection" to have a consistent structure.
>>>>> There are few ongoing sub-tasks, IMHO they are blockers for merge.
>>>>> So, I feel this branch is ready to merge into master branch.
>>>> I am not sure if I understand these two sentences together, I assume
>> you
>>>> planned to write "not blockers" in the first line (two lines seems to
>>>> have opposite meaning without this assumption).
>>>> Let me add some related thoughts: There are two implications/risks of
>>>> merging something to the master:
>>>> 1. Master can become more unstable
>>>> 2. Master will be delivered in the next release to the users
>>>> 1. seems to be fine, as it can be turned off, the risk is low, and we
>>>> can further decrease it with double-checking the stability based on the
>>>> mentioned checklist.
>>>> Second is more interesting and I am really interested about your
>>>> opinions: if we have a new feature on master, it will be part of the
>> new
>>>> release. If the feature is not functional-ready, yet (eg. list keys are
>>>> not working, yet), users who turn it on may be confused, as instead of
>> a
>>>> new (alpha-) feature they may get an inconsistent / faulty (?)
>> behavior.
>>>> We can communicate that the feature is still in alpha phase, but we
>> need
>>>> some level of functional completeness (IMHO).
>>>> As an example: SCM-HA is merged with completeness of security
>>>> implementation, but SCM-HA raft ring for non-secure clusters can be
>>>> started to test and functional complete. And we clearly communicate
>> that
>>>> security can not be used (yet).
>>>> What do you think?
>>>> Thanks again to start this discussion, (and if any help is required for
>>>> the merge related to build / ci / testing, I would be happy to help /
>>>> support it)
>>>> Marton
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
>>>> For additional commands, e-mail: dev-help@ozone.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to master
Posted by Shashikant Banerjee <sb...@cloudera.com.INVALID>.
+1
Thanks
Shashi
On Fri, Apr 9, 2021 at 1:39 PM Sadanand Shenoy <
sadanand.shenoy4898@gmail.com> wrote:
> +1, Thanks for working on this feature.
>
> Regards,
> Sadanand
>
> On Thu, Apr 8, 2021, 11:05 PM Rakesh Radhakrishnan <ra...@apache.org>
> wrote:
>
> > Thank you very much Yiqun and Marton for the feedback/useful comments.
> > Please find my responses below.
> >
> > @Yiqun,
> > As per the discussions, key deletion tasks have been implemented and the
> > basic functionality of #listKeys works as expected and will be improving
> it
> > further after merging the feature to master branch. Also, I've created a
> > follow-up umbrella jira for further optimizations/improvement tasks.
> >
> > @Marton,
> > [1] backward compatibility:
> > No backward compatibility issues. S3 works well as the feature code sits
> > behind the ozone.om.metadata.layout feature flag. Yes, same normalization
> > behavior as before. Even with feature turned ON the normalization
> behaviour
> > is the same, as the configuration "ozone.om.enable.filesystem.paths"
> should
> > be set to "true".
> >
> > [2] performance:
> > When it is turned OFF then there is zero performance penalty because the
> > existing functionality is not changed.
> >
> > With the feature flag turned OFF, master code will create intermediate
> > directories during create. When it is turned ON the prefix code also
> does a
> > similar approach during create. But, surely we will be focusing on the
> > performance path post merge and improving it further.
> >
> > [3] documentation:
> >
> > Done. HDDS-5067. Thank you for the useful review comments.
> >
> > [4] security:
> > As you have pointed out, everything works as earlier and there are no
> > security implications because of the feature.
> >
> > [5] branch merging" checklist:
> > I've updated the feature merge wiki page
> > <
> >
> https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
> > >.
> > Thanks!
> >
> > [6] >>> I assume you planned to write "not blockers" in the first line
> > I’m really sorry for the typo. Yes, "those are not blockers for the
> merge".
> > All the in progress tasks have been implemented now.
> >
> > [7] >>> We can communicate that the feature is still in alpha phase
> >
> > Yes, we have covered the basic functionalities and #listKeys basic part
> > works fine. We have added unit test cases and acceptance test cases to
> > ensure stability and will be actively working to improve it further after
> > the merge.
> >
> > The feature is disabled by default and won’t affect the stability of the
> > master branch code.
> >
> >
> >
> > @Yiqun, @Marton
> > Welcome suggestions/feedback. Thanks again for your time and your
> > suggestions in shaping up this feature :-)
> >
> > Thanks,
> > Rakesh
> >
> > On Tue, Apr 6, 2021 at 2:05 PM Elek, Marton <el...@apache.org> wrote:
> >
> > >
> > > Thank you very much to start the discussion Rakesh (and thanks to work
> > > on this.)
> > >
> > > As this is something which can greatly improve the performance for the
> > > FS use-cases, I am really exited.
> > >
> > > To make sure that we can guarantee the stability of the master branch,
> I
> > > would recommend to fill the "branch merging" checklist:
> > >
> > > https://cwiki.apache.org/confluence/display/OZONE/Merging+branches
> > >
> > > It would also provide additional information for all the contributors
> > > who would prefer to test this feature before/during the vote.
> > >
> > > I am especially interested about:
> > >
> > > 1. backward compatibility: if I understand well, it's an optional
> > > feature, so we can use s3 interface as before. But what about if we
> turn
> > > this feature off, what can we expect from the s3 interface? Do we have
> > > exactly the same normalization behavior as before or it's changed (I
> > > have no problem with any way, as it can be turned on and off, but
> > curious).
> > >
> > > 2. performance: this is already shared on the wiki page, and it's
> > > awesome. One minor question: as far as I understood we have slightly
> > > more overhead on the normal path (we should update / query multiple
> > > rocksdb tables). I don't assume significant slowness there, but do we
> > > have any measurements / numbers related to normal key creation vs
> master?
> > >
> > > 3. documentation: It would be great to have at least a basic level
> > > documentation as part of 'hadoop-hdds/docs'. It would help us to
> further
> > > test it in different environments.
> > >
> > > 4. security: I am interested if there are any security implication of
> > > security checks are modified (I assume everything works as before, but
> > > would be great to have confirmation / more information)
> > >
> > >
> > >
> > > > *Ozone wiki page:*
> > >
> > > >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
> > >
> > >
> > > Thanks to share all these information. I found that some of the
> > > sub-pages have confusing URLs:
> > >
> > > https://cwiki.apache.org/confluence/display/OZONE/Configurations
> > > https://cwiki.apache.org/confluence/display/OZONE/Documents
> > >
> > > These pages are related to the branch but URL may suggest that these
> are
> > > generic, Ozone related information.
> > >
> > > To fix this, I merged all the subpages to one page and moved the page
> > > under the "Merging branch subsection" to have a consistent structure.
> > >
> > >
> > >
> > > > There are few ongoing sub-tasks, IMHO they are blockers for merge.
> > >
> > > > So, I feel this branch is ready to merge into master branch.
> > >
> > >
> > > I am not sure if I understand these two sentences together, I assume
> you
> > > planned to write "not blockers" in the first line (two lines seems to
> > > have opposite meaning without this assumption).
> > >
> > > Let me add some related thoughts: There are two implications/risks of
> > > merging something to the master:
> > >
> > > 1. Master can become more unstable
> > > 2. Master will be delivered in the next release to the users
> > >
> > >
> > > 1. seems to be fine, as it can be turned off, the risk is low, and we
> > > can further decrease it with double-checking the stability based on the
> > > mentioned checklist.
> > >
> > > Second is more interesting and I am really interested about your
> > > opinions: if we have a new feature on master, it will be part of the
> new
> > > release. If the feature is not functional-ready, yet (eg. list keys are
> > > not working, yet), users who turn it on may be confused, as instead of
> a
> > > new (alpha-) feature they may get an inconsistent / faulty (?)
> behavior.
> > >
> > > We can communicate that the feature is still in alpha phase, but we
> need
> > > some level of functional completeness (IMHO).
> > >
> > > As an example: SCM-HA is merged with completeness of security
> > > implementation, but SCM-HA raft ring for non-secure clusters can be
> > > started to test and functional complete. And we clearly communicate
> that
> > > security can not be used (yet).
> > >
> > > What do you think?
> > >
> > >
> > >
> > > Thanks again to start this discussion, (and if any help is required for
> > > the merge related to build / ci / testing, I would be happy to help /
> > > support it)
> > >
> > > Marton
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> > > For additional commands, e-mail: dev-help@ozone.apache.org
> > >
> > >
> >
>
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to master
Posted by Sadanand Shenoy <sa...@gmail.com>.
+1, Thanks for working on this feature.
Regards,
Sadanand
On Thu, Apr 8, 2021, 11:05 PM Rakesh Radhakrishnan <ra...@apache.org>
wrote:
> Thank you very much Yiqun and Marton for the feedback/useful comments.
> Please find my responses below.
>
> @Yiqun,
> As per the discussions, key deletion tasks have been implemented and the
> basic functionality of #listKeys works as expected and will be improving it
> further after merging the feature to master branch. Also, I've created a
> follow-up umbrella jira for further optimizations/improvement tasks.
>
> @Marton,
> [1] backward compatibility:
> No backward compatibility issues. S3 works well as the feature code sits
> behind the ozone.om.metadata.layout feature flag. Yes, same normalization
> behavior as before. Even with feature turned ON the normalization behaviour
> is the same, as the configuration "ozone.om.enable.filesystem.paths" should
> be set to "true".
>
> [2] performance:
> When it is turned OFF then there is zero performance penalty because the
> existing functionality is not changed.
>
> With the feature flag turned OFF, master code will create intermediate
> directories during create. When it is turned ON the prefix code also does a
> similar approach during create. But, surely we will be focusing on the
> performance path post merge and improving it further.
>
> [3] documentation:
>
> Done. HDDS-5067. Thank you for the useful review comments.
>
> [4] security:
> As you have pointed out, everything works as earlier and there are no
> security implications because of the feature.
>
> [5] branch merging" checklist:
> I've updated the feature merge wiki page
> <
> https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
> >.
> Thanks!
>
> [6] >>> I assume you planned to write "not blockers" in the first line
> I’m really sorry for the typo. Yes, "those are not blockers for the merge".
> All the in progress tasks have been implemented now.
>
> [7] >>> We can communicate that the feature is still in alpha phase
>
> Yes, we have covered the basic functionalities and #listKeys basic part
> works fine. We have added unit test cases and acceptance test cases to
> ensure stability and will be actively working to improve it further after
> the merge.
>
> The feature is disabled by default and won’t affect the stability of the
> master branch code.
>
>
>
> @Yiqun, @Marton
> Welcome suggestions/feedback. Thanks again for your time and your
> suggestions in shaping up this feature :-)
>
> Thanks,
> Rakesh
>
> On Tue, Apr 6, 2021 at 2:05 PM Elek, Marton <el...@apache.org> wrote:
>
> >
> > Thank you very much to start the discussion Rakesh (and thanks to work
> > on this.)
> >
> > As this is something which can greatly improve the performance for the
> > FS use-cases, I am really exited.
> >
> > To make sure that we can guarantee the stability of the master branch, I
> > would recommend to fill the "branch merging" checklist:
> >
> > https://cwiki.apache.org/confluence/display/OZONE/Merging+branches
> >
> > It would also provide additional information for all the contributors
> > who would prefer to test this feature before/during the vote.
> >
> > I am especially interested about:
> >
> > 1. backward compatibility: if I understand well, it's an optional
> > feature, so we can use s3 interface as before. But what about if we turn
> > this feature off, what can we expect from the s3 interface? Do we have
> > exactly the same normalization behavior as before or it's changed (I
> > have no problem with any way, as it can be turned on and off, but
> curious).
> >
> > 2. performance: this is already shared on the wiki page, and it's
> > awesome. One minor question: as far as I understood we have slightly
> > more overhead on the normal path (we should update / query multiple
> > rocksdb tables). I don't assume significant slowness there, but do we
> > have any measurements / numbers related to normal key creation vs master?
> >
> > 3. documentation: It would be great to have at least a basic level
> > documentation as part of 'hadoop-hdds/docs'. It would help us to further
> > test it in different environments.
> >
> > 4. security: I am interested if there are any security implication of
> > security checks are modified (I assume everything works as before, but
> > would be great to have confirmation / more information)
> >
> >
> >
> > > *Ozone wiki page:*
> >
> > >
> >
> >
> https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
> >
> >
> > Thanks to share all these information. I found that some of the
> > sub-pages have confusing URLs:
> >
> > https://cwiki.apache.org/confluence/display/OZONE/Configurations
> > https://cwiki.apache.org/confluence/display/OZONE/Documents
> >
> > These pages are related to the branch but URL may suggest that these are
> > generic, Ozone related information.
> >
> > To fix this, I merged all the subpages to one page and moved the page
> > under the "Merging branch subsection" to have a consistent structure.
> >
> >
> >
> > > There are few ongoing sub-tasks, IMHO they are blockers for merge.
> >
> > > So, I feel this branch is ready to merge into master branch.
> >
> >
> > I am not sure if I understand these two sentences together, I assume you
> > planned to write "not blockers" in the first line (two lines seems to
> > have opposite meaning without this assumption).
> >
> > Let me add some related thoughts: There are two implications/risks of
> > merging something to the master:
> >
> > 1. Master can become more unstable
> > 2. Master will be delivered in the next release to the users
> >
> >
> > 1. seems to be fine, as it can be turned off, the risk is low, and we
> > can further decrease it with double-checking the stability based on the
> > mentioned checklist.
> >
> > Second is more interesting and I am really interested about your
> > opinions: if we have a new feature on master, it will be part of the new
> > release. If the feature is not functional-ready, yet (eg. list keys are
> > not working, yet), users who turn it on may be confused, as instead of a
> > new (alpha-) feature they may get an inconsistent / faulty (?) behavior.
> >
> > We can communicate that the feature is still in alpha phase, but we need
> > some level of functional completeness (IMHO).
> >
> > As an example: SCM-HA is merged with completeness of security
> > implementation, but SCM-HA raft ring for non-secure clusters can be
> > started to test and functional complete. And we clearly communicate that
> > security can not be used (yet).
> >
> > What do you think?
> >
> >
> >
> > Thanks again to start this discussion, (and if any help is required for
> > the merge related to build / ci / testing, I would be happy to help /
> > support it)
> >
> > Marton
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> > For additional commands, e-mail: dev-help@ozone.apache.org
> >
> >
>
Re: [DISCUSS] - Merge FileSystem Optimizations branch HDDS-2939 to master
Posted by Rakesh Radhakrishnan <ra...@apache.org>.
Thank you very much Yiqun and Marton for the feedback/useful comments.
Please find my responses below.
@Yiqun,
As per the discussions, key deletion tasks have been implemented and the
basic functionality of #listKeys works as expected and will be improving it
further after merging the feature to master branch. Also, I've created a
follow-up umbrella jira for further optimizations/improvement tasks.
@Marton,
[1] backward compatibility:
No backward compatibility issues. S3 works well as the feature code sits
behind the ozone.om.metadata.layout feature flag. Yes, same normalization
behavior as before. Even with feature turned ON the normalization behaviour
is the same, as the configuration "ozone.om.enable.filesystem.paths" should
be set to "true".
[2] performance:
When it is turned OFF then there is zero performance penalty because the
existing functionality is not changed.
With the feature flag turned OFF, master code will create intermediate
directories during create. When it is turned ON the prefix code also does a
similar approach during create. But, surely we will be focusing on the
performance path post merge and improving it further.
[3] documentation:
Done. HDDS-5067. Thank you for the useful review comments.
[4] security:
As you have pointed out, everything works as earlier and there are no
security implications because of the feature.
[5] branch merging" checklist:
I've updated the feature merge wiki page
<https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939>.
Thanks!
[6] >>> I assume you planned to write "not blockers" in the first line
I’m really sorry for the typo. Yes, "those are not blockers for the merge".
All the in progress tasks have been implemented now.
[7] >>> We can communicate that the feature is still in alpha phase
Yes, we have covered the basic functionalities and #listKeys basic part
works fine. We have added unit test cases and acceptance test cases to
ensure stability and will be actively working to improve it further after
the merge.
The feature is disabled by default and won’t affect the stability of the
master branch code.
@Yiqun, @Marton
Welcome suggestions/feedback. Thanks again for your time and your
suggestions in shaping up this feature :-)
Thanks,
Rakesh
On Tue, Apr 6, 2021 at 2:05 PM Elek, Marton <el...@apache.org> wrote:
>
> Thank you very much to start the discussion Rakesh (and thanks to work
> on this.)
>
> As this is something which can greatly improve the performance for the
> FS use-cases, I am really exited.
>
> To make sure that we can guarantee the stability of the master branch, I
> would recommend to fill the "branch merging" checklist:
>
> https://cwiki.apache.org/confluence/display/OZONE/Merging+branches
>
> It would also provide additional information for all the contributors
> who would prefer to test this feature before/during the vote.
>
> I am especially interested about:
>
> 1. backward compatibility: if I understand well, it's an optional
> feature, so we can use s3 interface as before. But what about if we turn
> this feature off, what can we expect from the s3 interface? Do we have
> exactly the same normalization behavior as before or it's changed (I
> have no problem with any way, as it can be turned on and off, but curious).
>
> 2. performance: this is already shared on the wiki page, and it's
> awesome. One minor question: as far as I understood we have slightly
> more overhead on the normal path (we should update / query multiple
> rocksdb tables). I don't assume significant slowness there, but do we
> have any measurements / numbers related to normal key creation vs master?
>
> 3. documentation: It would be great to have at least a basic level
> documentation as part of 'hadoop-hdds/docs'. It would help us to further
> test it in different environments.
>
> 4. security: I am interested if there are any security implication of
> security checks are modified (I assume everything works as before, but
> would be great to have confirmation / more information)
>
>
>
> > *Ozone wiki page:*
>
> >
>
> https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
>
>
> Thanks to share all these information. I found that some of the
> sub-pages have confusing URLs:
>
> https://cwiki.apache.org/confluence/display/OZONE/Configurations
> https://cwiki.apache.org/confluence/display/OZONE/Documents
>
> These pages are related to the branch but URL may suggest that these are
> generic, Ozone related information.
>
> To fix this, I merged all the subpages to one page and moved the page
> under the "Merging branch subsection" to have a consistent structure.
>
>
>
> > There are few ongoing sub-tasks, IMHO they are blockers for merge.
>
> > So, I feel this branch is ready to merge into master branch.
>
>
> I am not sure if I understand these two sentences together, I assume you
> planned to write "not blockers" in the first line (two lines seems to
> have opposite meaning without this assumption).
>
> Let me add some related thoughts: There are two implications/risks of
> merging something to the master:
>
> 1. Master can become more unstable
> 2. Master will be delivered in the next release to the users
>
>
> 1. seems to be fine, as it can be turned off, the risk is low, and we
> can further decrease it with double-checking the stability based on the
> mentioned checklist.
>
> Second is more interesting and I am really interested about your
> opinions: if we have a new feature on master, it will be part of the new
> release. If the feature is not functional-ready, yet (eg. list keys are
> not working, yet), users who turn it on may be confused, as instead of a
> new (alpha-) feature they may get an inconsistent / faulty (?) behavior.
>
> We can communicate that the feature is still in alpha phase, but we need
> some level of functional completeness (IMHO).
>
> As an example: SCM-HA is merged with completeness of security
> implementation, but SCM-HA raft ring for non-secure clusters can be
> started to test and functional complete. And we clearly communicate that
> security can not be used (yet).
>
> What do you think?
>
>
>
> Thanks again to start this discussion, (and if any help is required for
> the merge related to build / ci / testing, I would be happy to help /
> support it)
>
> Marton
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> For additional commands, e-mail: dev-help@ozone.apache.org
>
>
Re: [VOTE] - Merge FileSystem Optimizations branch HDDS-2939 to
master
Posted by "Elek, Marton" <el...@apache.org>.
Thank you very much to start the discussion Rakesh (and thanks to work
on this.)
As this is something which can greatly improve the performance for the
FS use-cases, I am really exited.
To make sure that we can guarantee the stability of the master branch, I
would recommend to fill the "branch merging" checklist:
https://cwiki.apache.org/confluence/display/OZONE/Merging+branches
It would also provide additional information for all the contributors
who would prefer to test this feature before/during the vote.
I am especially interested about:
1. backward compatibility: if I understand well, it's an optional
feature, so we can use s3 interface as before. But what about if we turn
this feature off, what can we expect from the s3 interface? Do we have
exactly the same normalization behavior as before or it's changed (I
have no problem with any way, as it can be turned on and off, but curious).
2. performance: this is already shared on the wiki page, and it's
awesome. One minor question: as far as I understood we have slightly
more overhead on the normal path (we should update / query multiple
rocksdb tables). I don't assume significant slowness there, but do we
have any measurements / numbers related to normal key creation vs master?
3. documentation: It would be great to have at least a basic level
documentation as part of 'hadoop-hdds/docs'. It would help us to further
test it in different environments.
4. security: I am interested if there are any security implication of
security checks are modified (I assume everything works as before, but
would be great to have confirmation / more information)
> *Ozone wiki page:*
>
https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
Thanks to share all these information. I found that some of the
sub-pages have confusing URLs:
https://cwiki.apache.org/confluence/display/OZONE/Configurations
https://cwiki.apache.org/confluence/display/OZONE/Documents
These pages are related to the branch but URL may suggest that these are
generic, Ozone related information.
To fix this, I merged all the subpages to one page and moved the page
under the "Merging branch subsection" to have a consistent structure.
> There are few ongoing sub-tasks, IMHO they are blockers for merge.
> So, I feel this branch is ready to merge into master branch.
I am not sure if I understand these two sentences together, I assume you
planned to write "not blockers" in the first line (two lines seems to
have opposite meaning without this assumption).
Let me add some related thoughts: There are two implications/risks of
merging something to the master:
1. Master can become more unstable
2. Master will be delivered in the next release to the users
1. seems to be fine, as it can be turned off, the risk is low, and we
can further decrease it with double-checking the stability based on the
mentioned checklist.
Second is more interesting and I am really interested about your
opinions: if we have a new feature on master, it will be part of the new
release. If the feature is not functional-ready, yet (eg. list keys are
not working, yet), users who turn it on may be confused, as instead of a
new (alpha-) feature they may get an inconsistent / faulty (?) behavior.
We can communicate that the feature is still in alpha phase, but we need
some level of functional completeness (IMHO).
As an example: SCM-HA is merged with completeness of security
implementation, but SCM-HA raft ring for non-secure clusters can be
started to test and functional complete. And we clearly communicate that
security can not be used (yet).
What do you think?
Thanks again to start this discussion, (and if any help is required for
the merge related to build / ci / testing, I would be happy to help /
support it)
Marton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
Re: [VOTE] - Merge FileSystem Optimizations branch HDDS-2939 to
master
Posted by Nandakumar Vadivelu <nv...@cloudera.com.INVALID>.
+1 for the merge.
> On 05-Apr-2021, at 3:14 PM, Rakesh Radhakrishnan <ra...@apache.org> wrote:
>
> Hi All,
>
> I would like to propose prefix based FileSystem Optimizations (FSO) work
> HDDS-2939 <https://issues.apache.org/jira/browse/HDDS-2939> merging into
> Ozone master branch. This optimization is intended to support atomic rename
> and delete operations in Ozone namespace.
>
> Presently, a rename/delete operation can become prohibitively expensive for
> such directories which have large sub-trees/sub-paths. This optimization
> allows to perform rename, delete of any directory in a
> deterministic/constant time atomically.
>
> The main functionality has been implemented and supports o3fs, ofs and
> ObjectStore APIs, for details please refer to sub-tasks of HDDS-2939 which
> we have been actively working in the feature branch
> <https://github.com/apache/ozone/tree/HDDS-2939> for the last several
> months. There is a configuration to turn this feature ON and OFF while
> merging back to master, it will be turned OFF by default for now.
>
> Merging back to master will greatly help in stabilizing/testing the feature
> more rigorously while ensuring the ongoing work on the master branch is not
> negatively impacted by the feature as it is turned OFF by default.
>
> Following graph compares the performance between master(V0) and new
> optimized code(V1) for the delete op in an unsecure cluster. Rename op also
> has similar results. Please refer to the attached test report
> <https://issues.apache.org/jira/secure/attachment/13023395/Performance+Comparison+Between++Master+and+HDDS-2939+branch-Report-001.pdf>in
> jira for more details.
>
> *Ozone wiki page:*
> https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
>
> Number of JIRAs Resolved: 27
>
> Patch Available/WIP: 3 jira
>
> There are few ongoing sub-tasks, IMHO they are blockers for merge. We will
> be actively working on these sub-tasks.
>
> Detailed design document is available in JIRA :
>
> https://issues.apache.org/jira/secure/attachment/12991926/Ozone%20FS%20Namespace%20Proposal%20v1.0.docx
>
> https://issues.apache.org/jira/secure/attachment/13023399/OzoneFS%20Optimizations_DesignOverview_%20HDDS-2939.pdf
>
> Quick stats on combined HDDS-2939 Patch : Commits
> 8b8a7e3ec84ad14e7128ff5fb3ded542ea9080d7..6d76676d2956346895de630a96c182188f9f3e38
>
> 157 files changed, 16289 insertions(+), 776 deletions(-)
>
> Added/modified test cases= ~160
>
> Thanks a lot to all contributors/reviewers.
>
> So, I feel this branch is ready to merge into master branch. Could you
> please provide your feedback. If there are no objections, I will proceed
> for merge voting.
>
> Thanks,
>
> Rakesh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
Re: [VOTE] - Merge FileSystem Optimizations branch HDDS-2939 to master
Posted by Uma gangumalla <um...@apache.org>.
+1 thanks for the great work Rakesh and team.
Regards,
Uma
On Mon, Apr 5, 2021 at 2:44 AM Rakesh Radhakrishnan <ra...@apache.org>
wrote:
> Hi All,
>
> I would like to propose prefix based FileSystem Optimizations (FSO) work
> HDDS-2939 <https://issues.apache.org/jira/browse/HDDS-2939> merging into
> Ozone master branch. This optimization is intended to support atomic rename
> and delete operations in Ozone namespace.
>
> Presently, a rename/delete operation can become prohibitively expensive for
> such directories which have large sub-trees/sub-paths. This optimization
> allows to perform rename, delete of any directory in a
> deterministic/constant time atomically.
>
> The main functionality has been implemented and supports o3fs, ofs and
> ObjectStore APIs, for details please refer to sub-tasks of HDDS-2939 which
> we have been actively working in the feature branch
> <https://github.com/apache/ozone/tree/HDDS-2939> for the last several
> months. There is a configuration to turn this feature ON and OFF while
> merging back to master, it will be turned OFF by default for now.
>
> Merging back to master will greatly help in stabilizing/testing the feature
> more rigorously while ensuring the ongoing work on the master branch is not
> negatively impacted by the feature as it is turned OFF by default.
>
> Following graph compares the performance between master(V0) and new
> optimized code(V1) for the delete op in an unsecure cluster. Rename op also
> has similar results. Please refer to the attached test report
> <
> https://issues.apache.org/jira/secure/attachment/13023395/Performance+Comparison+Between++Master+and+HDDS-2939+branch-Report-001.pdf
> >in
> jira for more details.
>
> *Ozone wiki page:*
>
> https://cwiki.apache.org/confluence/display/OZONE/FileSystem+Optimizations+-+HDDS-2939
>
> Number of JIRAs Resolved: 27
>
> Patch Available/WIP: 3 jira
>
> There are few ongoing sub-tasks, IMHO they are blockers for merge. We will
> be actively working on these sub-tasks.
>
> Detailed design document is available in JIRA :
>
>
> https://issues.apache.org/jira/secure/attachment/12991926/Ozone%20FS%20Namespace%20Proposal%20v1.0.docx
>
>
> https://issues.apache.org/jira/secure/attachment/13023399/OzoneFS%20Optimizations_DesignOverview_%20HDDS-2939.pdf
>
> Quick stats on combined HDDS-2939 Patch : Commits
>
> 8b8a7e3ec84ad14e7128ff5fb3ded542ea9080d7..6d76676d2956346895de630a96c182188f9f3e38
>
> 157 files changed, 16289 insertions(+), 776 deletions(-)
>
> Added/modified test cases= ~160
>
> Thanks a lot to all contributors/reviewers.
>
> So, I feel this branch is ready to merge into master branch. Could you
> please provide your feedback. If there are no objections, I will proceed
> for merge voting.
>
> Thanks,
>
> Rakesh
>