[
https://issues.apache.org/jira/browse/HDFS-16208?focusedWorklogId=796227&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-796227
]
ASF GitHub Bot logged work on HDFS-16208:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 29/Jul/22 03:20
Start Date: 29/Jul/22 03:20
Worklog Time Spent: 10m
Work Description: jianghuazhu commented on PR #3376:
URL: https://github.com/apache/hadoop/pull/3376#issuecomment-1198838825
Thanks @prasad-acit .
I have read your update carefully, here are some of my personal insights:
1. We should hold child locks in FSDirDeleteOp, here are some of my
suggestions.
`FSDirDeleteOp#deleteInternal() {
''''''
fsd.getINodeMap().latchWriteLock(iip.getExistingINodes(), new INode[]{});
fsn.removeLeasesAndINodes(removedUCFiles, removedINodes, true);
''''''
}
`
At this stage, the deleteInternal() operation may be safer, and when FGL
becomes more mature, it can be processed more fine-grained.
2. Adding hasWriteLock() to PartitionedGSet may still fail to accurately
capture each Partition and lock. Because the elements saved in PartitionedGSet
will be repeated and distributed in different Partitions.
3. It seems unnecessary to add hasWriteLock() and latchWriteLock() to
INodeMap because latchWriteLock(INodesInPath iip, INode[] missing) already
exists.
Also, regarding the child lock issue you mentioned, I think it's a matter of
concern. I'll submit some PRs later.
Welcome to the discussion, @prasad-acit .
Issue Time Tracking
-------------------
Worklog Id: (was: 796227)
Time Spent: 1.5h (was: 1h 20m)
> [FGL] Implement Delete API with FGL
> -----------------------------------
>
> Key: HDFS-16208
> URL: https://issues.apache.org/jira/browse/HDFS-16208
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Renukaprasad C
> Assignee: Renukaprasad C
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Replace all global locks for file / directory deletion with FGL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
