[
https://issues.apache.org/jira/browse/HDDS-10631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang updated HDDS-10631:
-----------------------------------
Parent: HDDS-11445 (was: HDDS-7593)
> Any open key rename should ideally be blocked
> ---------------------------------------------
>
> Key: HDDS-10631
> URL: https://issues.apache.org/jira/browse/HDDS-10631
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: Siyao Meng
> Priority: Major
>
> Currently only *hsync'ed* open key rename will be blocked with the check:
> {code}
> if (fromKeyFileStatus.getKeyInfo().isHsync()) {
> throw new OMException("Open file cannot be renamed since it is " +
> "hsync'ed: volumeName=" + volumeName + ", bucketName=" +
> bucketName + ", key=" + fromKeyName, RENAME_OPEN_FILE);
> }
> {code}
> above snippet from
> https://github.com/apache/ozone/blob/cca6782d44a1417ac27897890eaac5cd097481de/hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/request/key/OMKeyRenameRequestWithFSO.java#L129-L133
> But we should ideally block any open key rename because any writes after that
> will fail. And because of that, the delayed exception in subsequent write
> only makes debugging harder
> Research to be done:
> 1. How are directory renames done in FSO buckets? Would this make it slower
> since it might be required to scan the whole openKeyTable (openFileTable) for
> that?
> Note:
> 1. This would no longer be needed if/when Ozone supports writes after renames
> (i.e. client no longer rely on key path, but use something other identifiers
> such as key object ID / inode
> ID)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
