[jira] [Commented] (HADOOP-13430) Optimize and fix getFileStatus in S3A

["Steve Loughran (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HADOOP-13430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153415#comment-16153415 ] 

Steve Loughran commented on HADOOP-13430:
-----------------------------------------

yes,  those existence checks [are really slow|https://steveloughran.blogspot.co.uk/2016/12/how-long-does-filesystemexists-take.html].

# open can just do a HEAD of the path, only if that's not found can it fall back to to a full getFileStatus (HADOOP-13712). 
# in create(overwrite=true) we don't need to look for the path existing, just verify that it's not a directory/got children, and that  there isn't a parent file (no need to look for any dir status). See HADOOP-13884 for some discussion there. Essentially: one HEAD dest + "/", one LIST dest " /", one HEAD parent(dest) to make sure it's not a file. There's no need to verify the parent is a dir (HEAD + LIST), because create() does a mkdirs() & will delete any empty parent dirs after the close() in a single POST. createNonRecursive will need that check, but as it avoids doing a full recursive "is there a parent file" check, it's actually more robust than what we have today.

The reason we've avoided the optimisation until now is that we've been looking @ S3guard for delivering significantly higher performance. We've also gone through a lot of downstream code and eliminated a lot of the pairs of existence & action checks (if file.exists() file.delete()), etc, which are doiing a full needless getFileStatus call. Now we've got a lot of those out the way, time to look at the core operations. 

See also 

> Optimize and fix getFileStatus in S3A
> -------------------------------------
>
>                 Key: HADOOP-13430
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13430
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: fs/s3
>    Affects Versions: 2.8.0
>            Reporter: Steven K. Wong
>            Assignee: Steven K. Wong
>            Priority: Minor
>         Attachments: HADOOP-13430.001.WIP.patch
>
>
> Currently, S3AFileSystem.getFileStatus(Path f) sends up to 3 requests to S3 when pathToKey(f) = key = "foo/bar" is a directory:
> 1. HEAD key=foo/bar \[continue if not found]
> 2. HEAD key=foo/bar/ \[continue if not found]
> 3. LIST prefix=foo/bar/ delimiter=/ max-keys=1
> My experience (and generally true, I reckon) is that almost all directories are nonempty directories without a "fake directory" file (e.g. "foo/bar/"). Under this condition, request #2 is mostly unhelpful; it only slows down getFileStatus. Therefore, I propose swapping the order of requests #2 and #3. The swapped HEAD request will be skipped in practically all cases.
> Furthermore, when key = "foo/bar" is a nonempty directory that contains a "fake directory" file (in addition to actual files), getFileStatus currently returns an S3AFileStatus with isEmptyDirectory=true, which is wrong. Swapping will fix this. The swapped LIST request will use max-keys=2 to determine isEmptyDirectory correctly. (Removing the delimiter from the LIST request should make the logic a little simpler than otherwise.)
> Note that key = "foo/bar/" has the same problem with isEmptyDirectory. To fix it, I propose skipping request #1 when key ends with "/". The price is this will, for an empty directory, replace a HEAD request with a LIST request that's generally more taxing on S3.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org