rakeshadr commented on a change in pull request #1682:
URL: https://github.com/apache/ozone/pull/1682#discussion_r544123278
##########
File path:
hadoop-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/request/key/OMAllocateBlockRequest.java
##########
@@ -192,6 +193,17 @@ public OMClientResponse
validateAndUpdateCache(OzoneManager ozoneManager,
KEY_NOT_FOUND);
}
+ if (ozoneManager.getEnableFileSystemPaths()) {
+ // Ensure the parent exist.
+ if (!"".equals(OzoneFSUtils.getParent(keyName))
Review comment:
>And also for performance reasons, can we leave allocateBlock, as during
KeyCommit anyway we shall figure it out?
On a second thought, it makes sense to me to avoid any additional DB calls
which can affect the OM performance. Most of the cases, parent directories
would exists in RocksDB offheap cache even then I would agree to skip parentDir
check considering the cost of DB call if not exist.
On the other side, I think there won't be any correctness issue if we skip
parent dir check in AllocateBlockReq. Later, we can bring this` fast-fail`
check based on user demand. Considering that, I'm +1 to skip extra DB check in
AllocateBlockReq now.
Thanks a lot @ayushtkn for your patience and taking care this. I agree to
revert the changes from OmAllocateBlockRequest.
>But I am not very aware about the performance impacts and HDDS-2939 both
In HDDS-2939, in order to fetch openFileName, it requires to traverse
top-down model and parentDir check won't add any additional overhead. For
example, say open file /a/b/c/d/file1.
_HDDS-2939 branch_: OM will fetch /a, /a/b, /a/b/c, /a/b/c/d from DirTable
and finally get /a/b/c/d/file1 from OpenFileTable. Here, one idea is to build
DirCache to reduce DB overhead. @bharatviswa504 was talking about this part in
his previous comment.
_Master branch_: OM will do point look up by fetching /a/b/c/d from
KeyTable. Here, existing RocksDB offheap cache would help.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
