[
https://issues.apache.org/jira/browse/HDFS-10850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15533129#comment-15533129
]
Daryn Sharp commented on HDFS-10850:
------------------------------------
I'm not sure querying the EZ for the parent directory is the right fix, and we
should consider that code other than hive depends on the old semantics.
Depending on which rename is called, and if the dest is a dir, it will move the
src _into_ the dest dir. So let's say I want to rename from /dir1/file to
/dir2/dir-with-EZ. The result may be /dir2/dir-with-EZ/file. If the parent is
queried, ie. /dir2, the rename will look like it should succeed (src and dest
have no EZ) but will fail. The old debatably broken semantics cover this case.
I realized another similar use case to consider. Let's I want to create a file
only if the path is under an EZ. Should I have to query the parent's EZ, catch
FNF, repeat until I find an EZ or hit the root dir? The no-FNF semantics
require 1 RPC.
In the end we may need to consider preserving the no-FNF semantics and add
specific exceptions.
> getEZForPath should NOT throw FNF
> ---------------------------------
>
> Key: HDFS-10850
> URL: https://issues.apache.org/jira/browse/HDFS-10850
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs
> Affects Versions: 2.8.0
> Reporter: Daryn Sharp
> Assignee: Rakesh R
> Priority: Blocker
>
> HDFS-9433 made an incompatible change to the semantics of getEZForPath. It
> used to return the EZ of the closest ancestor path. It never threw FNF. A
> common use of getEZForPath to determining if a file can be renamed, or must
> be copied due to mismatched EZs. Notably, this has broken hive.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
