[
https://issues.apache.org/jira/browse/HADOOP-16396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16876283#comment-16876283
]
Sean Mackrory commented on HADOOP-16396:
----------------------------------------
Submitted an iteration based on your feedback via PR. I moved
allowAuthoritative into S3Guard, as I agree simplifying S3AFS.java is
worthwhile. It's a bit messy because it needs 4 long parameter names or adding
getters to S3AFS anyway. I deduplicated a couple of the calls. I'd feel better
if we would rename "allowAuthoritativeMetadataStore" and
"allowAuthoritativePaths" to "authMode" and "authModePaths". So far, "auth
mode" is just a short-hand being thrown around - any objection to formalizing
that in code?
Renamed unguardedFS to rawFS. I'd like to keep "fullyAuthFS" to distinguish
between other "guarded" FS that have other varying settings for authoritative
paths, etc. I have a rather unique need for the other get*FS functions that
take a directory as an argument, I think, so I'd rather not factor those out.
I removed createNonAuthFS since I was indeed no longer using it.
> Allow authoritative mode on a subdirectory
> ------------------------------------------
>
> Key: HADOOP-16396
> URL: https://issues.apache.org/jira/browse/HADOOP-16396
> Project: Hadoop Common
> Issue Type: Improvement
> Components: fs/s3
> Reporter: Sean Mackrory
> Assignee: Sean Mackrory
> Priority: Major
> Attachments: HADOOP-16396.001.patch, HADOOP-16396.002.patch,
> HADOOP-16396.003.patch
>
>
> Let's allow authoritative mode to be applied only to a subset of a bucket.
> This is coming primarily from a Hive warehousing use-case where Hive-managed
> tables can benefit from query planning, but can't speak for the rest of the
> bucket. This should be limited in scope and is not a general attempt to allow
> configuration on a per-path basis, as configuration is currently done on a
> per-process of a per-bucket basis.
> I propose a new property (we could overload
> fs.s3a.metadatastore.authoritative, but that seems likely to cause confusion
> somewhere). A string would be allowed that would then be qualified in the
> context of the FileSystem, and used to check if it is a prefix for a given
> path. If it is, we act as though authoritative mode is enabled. If not, we
> revert to the existing behavior of fs.s3a.metadatastore.authoritative (which
> in practice will probably be false, the default, if the new property is in
> use).
> Let's be clear about a few things:
> * Currently authoritative mode only short-cuts the process to avoid a
> round-trip to S3 if we know it is safe to do so. This means that even when
> authoritative mode is enabled for a bucket, if the metadata store does not
> have a complete (or "authoritative") current listing cached, authoritative
> mode still has no effect. This will still apply.
> * This will only apply to getFileStatus and listStatus, and internal calls to
> their internal counterparts. No other API is currently using authoritative
> mode to change behavior.
> * This will only apply to getFileStatus and listStatus calls INSIDE the
> configured prefix. If there is a recursvie listing on the parent of the
> configured prefix, no change in behavior will be observed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
