org.apache.hadoop.fs.s3a.impl

Class DeleteOperation

java.lang.Object

org.apache.hadoop.fs.s3a.impl.AbstractStoreOperation

org.apache.hadoop.fs.s3a.impl.ExecutingStoreOperation<Boolean>

org.apache.hadoop.fs.s3a.impl.DeleteOperation

public class DeleteOperation
extends ExecutingStoreOperation<Boolean>

Implementation of the delete() operation.

How S3Guard/Store inconsistency is handled:

1. The list operation does not ask for tombstone markers; objects under tombstones will be found and deleted. The extraFilesDeleted counter will be incremented here.
2. That may result in recently deleted files being found and duplicate delete requests issued. This is mostly harmless.
3. If a path is considered authoritative on the client, so only S3Guard is used for listings, we wrap up the delete with a scan of raw S3. This will find and eliminate OOB additions.
4. Exception 1: simple directory markers of the form PATH + "/". These are treated as a signal that there are no children; no listing is made.
5. Exception 2: delete(path, true) where path has a tombstone in S3Guard. Here the delete is downgraded to a no-op even before this operation is created. Thus: no listings of S3.

If this class is logged at debug, requests will be audited: the response to a bulk delete call will be reviewed to see if there were fewer files deleted than requested; that will be printed at WARN level. This is independent of handling rejected delete requests which raise exceptions -those are processed lower down.

Performance tuning:

The operation to POST a delete request (or issue many individual DELETE calls) then update the S3Guard table is done in an async operation so that it can overlap with the LIST calls for data. However, only one single operation is queued at a time.

Executing more than one batch delete is possible, it just adds complexity in terms of error handling as well as in the datastructures used to track outstanding operations. If this is done, then it may be good to experiment with different page sizes. The default value is InternalConstants.MAX_ENTRIES_TO_DELETE, the maximum a single POST permits.

1. Smaller pages executed in parallel may have different performance characteristics when deleting very large directories, because it will be the DynamoDB calls which will come to dominate. Any exploration of options here MUST be done with performance measurements taken from test runs in EC2 against local DDB and S3 stores, so as to ensure network latencies do not skew the results.

2. Note that as the DDB thread/connection pools will be shared across all active delete operations, speedups will be minimal unless those pools are large enough to cope the extra load.

There are also some opportunities to explore in DynamoDBMetadataStore with batching delete requests in the DDB APIs.

Constructor Summary

Constructors

Constructor and Description
DeleteOperation(StoreContext context, S3AFileStatus status, boolean recursive, OperationCallbacks callbacks, int pageSize) Constructor.

Method Summary

Modifier and Type	Method and Description
protected void	deleteDirectoryTree(org.apache.hadoop.fs.Path path, String dirKey) Delete a directory tree.
Boolean	execute() Delete a file or directory tree.
long	getExtraFilesDeleted()
long	getFilesDeleted()

Methods inherited from class org.apache.hadoop.fs.s3a.impl.ExecutingStoreOperation

executeOnlyOnce

Methods inherited from class org.apache.hadoop.fs.s3a.impl.AbstractStoreOperation

getStoreContext

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

DeleteOperation

public DeleteOperation(StoreContext context,
                       S3AFileStatus status,
                       boolean recursive,
                       OperationCallbacks callbacks,
                       int pageSize)

Constructor.

Parameters:

context - store context

status - pre-fetched source status

recursive - recursive delete?

callbacks - callback provider

pageSize - size of delete pages

Method Detail

getFilesDeleted

public long getFilesDeleted()

getExtraFilesDeleted

public long getExtraFilesDeleted()

execute

@Retries.RetryTranslated
public Boolean execute()
                                         throws IOException

Delete a file or directory tree.

This call does not create any fake parent directory; that is left to the caller. The actual delete call is done in a separate thread. Only one delete at a time is submitted, however, to reduce the complexity of recovering from failures.

The DynamoDB store deletes paths in parallel itself, so that potentially slow part of the process is somewhat speeded up. The extra parallelization here is to list files from the store/DDB while that delete operation is in progress.

Specified by:

execute in class ExecutingStoreOperation<Boolean>

Returns:

true, except in the corner cases of root directory deletion

Throws:

org.apache.hadoop.fs.PathIsNotEmptyDirectoryException - if the path is a dir and this is not a recursive delete.

IOException - list failures or an inability to delete a file.

deleteDirectoryTree

@Retries.RetryTranslated
protected void deleteDirectoryTree(org.apache.hadoop.fs.Path path,
                                                            String dirKey)
                                                     throws IOException

Delete a directory tree.

This is done by asking the filesystem for a list of all objects under the directory path, without using any S3Guard tombstone markers to hide objects which may be returned in S3 listings but which are considered deleted.

Once the first pageSize worth of objects has been listed, a batch delete is queued for execution in a separate thread; subsequent batches block waiting for the first call to complete or fail before again, being deleted in the separate thread.

After all listed objects are queued for deletion, if the path is considered authoritative in the client, a final scan of S3 without S3Guard is executed, so as to find and delete any out-of-band objects in the tree.

Parameters:

path - directory path

dirKey - directory key

Throws:

IOException - failure