rakeshadr commented on a change in pull request #1607:
URL: https://github.com/apache/ozone/pull/1607#discussion_r528451116



##########
File path: 
hadoop-ozone/ozonefs-common/src/main/java/org/apache/hadoop/fs/ozone/BasicOzoneFileSystem.java
##########
@@ -498,6 +498,14 @@ public boolean delete(Path f, boolean recursive) throws 
IOException {
     incrementCounter(Statistic.INVOCATION_DELETE, 1);
     statistics.incrementWriteOps(1);
     LOG.debug("Delete path {} - recursive {}", f, recursive);
+
+    String layOutVersion = adapter.getBucketLayoutVersion();
+    if (layOutVersion != null &&
+            OMConfigKeys.OZONE_OM_LAYOUT_VERSION_V1.equals(layOutVersion)) {
+      String key = pathToKey(f);
+      return adapter.deleteObject(key);

Review comment:
       Thanks a lot @linyiqun for the reviews.
   
   This patch is removing the given keyPath from the DirTable(if its a dir) or 
from the KeyTable(if its a file). Presently, it is not checking whether the dir 
is empty or not then handle it based on recursive flag.
   
   _**Need to implement: Point-1**_: I've to pass the 'recursive' flag to the 
OM then throw OMException("Directory is not empty") if `recursive==true && 
keyPath#isNotEmptyDir()`. This I will do in current PR on next commit.
   
   _**Need to implement: Point-2**_: Like I mentioned in the description, once 
the given keyPath is removed it requires cleanup of sub-dirs/files for a 
non-empty parent. Since the parent doesn't exists the traversal logic will not 
be able to find its children. For example: '/a/b/c/d/e/file1'. Now user deletes 
'/b' , then the key entry '<parentID>/b=<objectID>' will be removed on the user 
call path. Assume parentID=1023 and objectID=1024. Deletion of '1023/b=1024' 
key hides all its children and become orphan. '1024/c'. Now, these garbage has 
to cleaned up async way and can be done via HDDS-4495.
   
   _**Need to implement: Point-3**_: Also, for the above point-2, it has to 
modify the existing KeyDeletingService to delete all the file-blocks. I will 
analyse these flow during HDDS-4495 implementation then will handle it based on 
the complexity.
   
   IMHO, Point-2 & Point-3 can be done separately as its not affecting the 
functionality of recursive or non-recursive deletion. Does this make sense to 
you?
   




----------------------------------------------------------------
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]

Reply via email to