Details
-
Sub-task
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
Currently, the deleting speed of paths in the FSO bucket is too slow.
Every time the DirectoryDeletingService executes(every 1m by default), it chooses only one path from DeletedDirectroyTable and tries adding its sub-files and sub-dirs into the PurgeDirectories Request. The real deletion happens in OMKeyDeleteResponseWithFSO, which moved all sub-dirs into DeletedDirectroyTable. Then these sub-dirs will be chosen by the future execution of DirectoryDeletingService.
In the real production environment, such deletion speed is not applicable. There could be lots of dirs deleted without sub-dirs or sub-files. The dir deletion speed would lag behind the dir creation speed.
I propose to optimize the logic of the DirectoryDeletingService, we could consume all the quota (ozone.path.deleting.limit.per.task) to delete paths as much as possible. The good news is the PB is already designed to do so, we could add more PurgePathRequest in one PurgeDirectoriesRequest.
-----------------------------------
This should be compatible with HDDS-5048.
This aims to improve the efficiency of the deletion if not enough sub-files or sub-dirs are chosen.
Attachments
Issue Links
- causes
-
HDDS-7447 Leak of TableIterator in DirectoryDeletingService.
- Resolved
- is related to
-
HDDS-5048 [FSO] Perf optimization - Recursively visit sub-path components and do cleanup
- Resolved
-
HDDS-7541 FSO recursive delete directory with hierarchy takes much time for cleanup
- Resolved
-
HDDS-7147 DirectoryDeletingService interval unit mismatch
- Resolved
-
HDDS-7592 Recursive delete of directory multiple time impacts some directory not removed
- Resolved
- links to