[
https://issues.apache.org/jira/browse/HDDS-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245276#comment-17245276
]
Sadanand Shenoy edited comment on HDDS-3367 at 12/7/20, 3:34 PM:
-----------------------------------------------------------------
{quote}Can you please share more information about the motivation?
{quote}
Out of the approaches suggested in the design doc , we have decided to go with
the approach in where the _existing hadoop trash emptier is extended_ mostly
because it is a simpler approach. One of the cons listed under this approach is
that the hadoop trash emptier is single threaded .To tackle this, we are making
it multithreaded such that each thread operates on a bucket level. The other
con stated in there is that introducing an ozone filesystem instance for the
purpose of trash emptier means that the server needs to maintain client jars .
To solve this, we will be creating a filesystem for trash specific operations /
use the OM api directly in the server itself that doesn’t cause the overhead of
an RPC.
The feature is functional right now with the first patch being implemented and
we are in the cleaning up/performance improvement stage. The filesystem
dependency will be removed in the later patches as the feature implementation
is closed (directly using OM apis). Although we are going with this approach,
we will re-evaluate the approaches later after evaluating the performance.
was (Author: sadanand_shenoy):
{quote}Can you please share more information about the motivation?
{quote}
Out of the approaches suggested in the design doc , we have decided to go with
the approach in where the _existing hadoop trash emptier is extended_ mostly
because it is a simpler approach. One of the cons listed under this approach is
that the hadoop trash emptier is single threaded .To tackle this, we are making
it multithreaded such that each thread operates on a bucket level. The other
con stated in there is that introducing an ozone filesystem instance for the
purpose of trash emptier means that the server needs to maintain client jars .
To solve this, we will be creating a filesystem for trash specific operations /
use the OM api directly in the server itself that doesn’t cause the overhead of
an RPC.
The feature is functional right now with the first patch being implemented and
we are in the cleaning up/performance improvement stage. The filesystem
dependency will be removed in the later patches as the feature implementation
is closed (directly using OM apis). Although we are going with this approach,
we will re-evaluate the approaches later after evaluating the performance.
> Trash Support for Ozone FileSystem
> ----------------------------------
>
> Key: HDDS-3367
> URL: https://issues.apache.org/jira/browse/HDDS-3367
> Project: Hadoop Distributed Data Store
> Issue Type: New Feature
> Components: Ozone Filesystem
> Affects Versions: 1.0.0
> Reporter: Sadanand Shenoy
> Assignee: Sadanand Shenoy
> Priority: Blocker
> Attachments: OzoneFilesystemTrashImplementation.pdf,
> OzoneFsTrash.patch
>
>
> The aim of this jira to add the trash feature capability in ozone that will
> help prevent accidental deletion of files and directories. When a file gets
> deleted in Ozone, the file is not immediately expelled from Ozone but will be
> moved to trash. Similarly as in HDFS, to immediately delete a file, a
> skipTrash option will be provided. The jira also aims to integrate the Ozone
> FS Trash to the Trash API developed as a part of HDDS-2416.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
