[
https://issues.apache.org/jira/browse/HADOOP-13651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606983#comment-15606983
]
Aaron Fabbri commented on HADOOP-13651:
---------------------------------------
Hey [~eddyxu], thank you for the thorough review!
{quote}The deletion on metadata store should happen before on S3. {quote}
Interesting idea. My thinking was, deletion of data is an important task (i.e.
security concerns). If MetadataStore fails, I'd rather delete underlying data,
and risk subsequent eventual consistency (unexpected FileNotFound) on that path
since MetadataStore did not get updated.
If S3A fails in your proposal, then we mark file as deleted for MetadataStore
clients, but the data is still there. Technically the MetadataStore deletion
would need to be rolled back, or else clients which retry the delete would fail
(file does not exist, according to MetadataStore). So your proposal, I think,
requires the introduction of transactions in that we need logic to to
rollbacks. I prefer to just fail to update the MetadataStore after S3
modification, log an error, and suffer the consequences of eventual consistency
on that path.
{quote}It might be problematic for delete-after-listing case. {quote}
Yep good catch.. thus the TODO comment. I mention above that I am not doing
delete support in this patch and prefer to do it as a separate folllowup JIRA
so it is easier to get a good code review. That TODO comment is where we will
check {{PathMetadata.isDeleted()}}, and treat the file as deleted. There are a
number of spots we need to do this.
{quote}So listStatus will go through this code if either allowAuthoritative ==
false or dirMeta == null or dirMeta.isAuthorizative == null. I don't fully
understand what scenarios each condition represents. Can you explain a little
bit how each case happens?{quote}
If {{fs.s3a.metadatastore.authoritative}} is set to false, the client always
will consult S3 in addition to the Metadata store. This has worse performance,
but allows for use cases like an external process adding data to S3.
If there is no dirMeta, the MetadataStore has no state, so we have to consult
S3.
If dirMeta.isAuthoritative is false, the MetadataStore is saying it does not
have full state for this directory (i.e. client never did a put(DirMeta w/
authoritative=true), or MetadataStore does not support being authoritative for
directory listing.
{quote}I think it is safer that after this point, just do retries to S3 (or
both of them) until these two sets of files (from MS and S3) are equal.{quote}
Interesting.. or you could be more efficient, and retry only when the client
actually tries to read the file. Anyways, I purposely left retries out of
this, preferring to do it in later JIRA. Again, for easier code reviews. For
now there are TODO comments in most of the places it is needed.
{quote}In finishedWrite(), you need also update the parent directory
isEmptyDirectory() flag, similar to wha
t{{deleteUnccessaryFakeDirectories(p.getParent())}} does.{quote}
finishedWrite() calls MetadataStore.put(), which is where I'm updating
isEmptyDirectory().. I don't love doing that in the MetadataStore, but out of 2
or 3 algorithms, it was the best I came up with. isEmptyDirectory is a pain.
{quote}
The checks for isNullMetadataStore() seems not necessary, as NullMetadataStore
is supposed to do nothing.
{quote}
I thought about omitting it, but we'd be creating a bunch of garbage with zero
purpose. Here's the function comment:
{code}
/**
* Although NullMetadataStore does nothing, callers may wish to avoid work
* (fast path) when the NullMetadataStore is in use.
* @param ms The MetadataStore to test
* @return true iff the MetadataStore is the null, or no-op, implementation.
*/
public static boolean isNullMetadataStore(MetadataStore ms) {
{code}
{code}
The patch seems not be able to be cleanly patched to the latest HADOOP-13345.
{code}
Yep. It depends on HADOOP-13631 which needs to go in before I can submit this
patch.
> S3Guard: S3AFileSystem Integration with MetadataStore
> -----------------------------------------------------
>
> Key: HADOOP-13651
> URL: https://issues.apache.org/jira/browse/HADOOP-13651
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/s3
> Reporter: Aaron Fabbri
> Assignee: Aaron Fabbri
> Attachments: HADOOP-13651-HADOOP-13345.001.patch,
> HADOOP-13651-HADOOP-13345.002.patch
>
>
> Modify S3AFileSystem et al. to optionally use a MetadataStore for metadata
> consistency and caching.
> Implementation should have minimal overhead when no MetadataStore is
> configured.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
