[ 
https://issues.apache.org/jira/browse/HDDS-9095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17749086#comment-17749086
 ] 

Kaijie Chen edited comment on HDDS-9095 at 7/31/23 8:46 AM:
------------------------------------------------------------

Thanks [~ivanandika] for digging into this issue. Sorry for causing this issue 
in the first place.

Personally I prefer the isMultipartKey way, because the end result will be 
cleaner.

IIUC, isMultipartKey is only for open keys. It's likely existing open MPU  keys 
are already in an orphan state (or eventually will be). Can we just rely on 
this ticket to fix the problem afterwards? (Of course we can provide a db fix 
tool to fix the problem in advance.)

Besides, is it OK to only keep the "without failing when open MPU keys do not 
exist" logic? Or can we add a optional fail/nofail flag to reuse the logic? 


was (Author: ckj996):
Thanks [~ivanandika] for digging into this issue. Sorry for causing this issue 
in the first place.

Personally I prefer the isMultipartKey way, because the end result will be 
cleaner.

IIUC, isMultipartKey is only for open keys. It's likely existing open MPU  keys 
are already in an orphan state (or eventually will be). Can we just rely on 
this ticket to fix the problem afterwards? (Of course we can provide a db fix 
tool to fix the problem in advance.)

Besides, is it OK to only keep the "without failing when open MPU keys do not 
exist" logic? Or can we add a optional flag to reuse the logic? 

> Implement cleanup service for MultipartInfoTable
> ------------------------------------------------
>
>                 Key: HDDS-9095
>                 URL: https://issues.apache.org/jira/browse/HDDS-9095
>             Project: Apache Ozone
>          Issue Type: Improvement
>          Components: OM
>            Reporter: Ivan Andika
>            Assignee: Ivan Andika
>            Priority: Major
>             Fix For: 1.4.0
>
>
> In our cluster, there are around few thousands MPU keys in 
> multipartInfoTable, with some of them being few months old. 
> The reason is that these MPU keys are already initiated, and possibly 
> committed few parts, but was not completed / aborted by the user. These 
> spaces can be freed.  
> Similar to the cleanup service OM open key table (HDDS-4120), we can 
> implement clean up on MultipartInfoTable (and related open keys in 
> OpenKeyTable) using a background job. -However, instead of using a new OM 
> request / response, we can reuse the OM MPU abort request / response instead, 
> which already handles the cleanup (i.e. expired inflight MPU can be aborted 
> after a defined expiry threshold).-



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to