[ https://issues.apache.org/jira/browse/HDFS-7878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16140300#comment-16140300 ]
Chris Douglas commented on HDFS-7878: ------------------------------------- bq. the "better" calls. Fine by me. If this JIRA only added an option to the builder for {{open}}, that would satisfy most of our use cases. bq. I'm a bit confused as to what a PathHandle to an as yet uncreated path would be? I was thinking we could expose the inode ID for the target directory. HDFS doesn't supply this now, but it could. The FS implementations over object stores might have trouble supporting it. bq. doing this in FileContext would be better Maybe? This came up during the [discussion|https://issues.apache.org/jira/browse/HADOOP-12910?focusedCommentId=15189492&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15189492] of async renames. We keep suggesting that we push functionality and users to that API, but it's not happening. I like the idea of making {{FileContext}} into an "advanced" API that allows clients to reason about consistency, visibility, performance, and durability. But for the near and foreseeable future, most of us need the "open by file ID" API. bq. I know I've been doing things underneath FileSystem, but that doesn't mean we should do more in terms of evolving that API. I won't ask for consistency, but I will ask for a short path through this particular issue. HDFS-6984 took a very long detour while I incorporated all the feedback. > API - expose an unique file identifier > -------------------------------------- > > Key: HDFS-7878 > URL: https://issues.apache.org/jira/browse/HDFS-7878 > Project: Hadoop HDFS > Issue Type: Improvement > Reporter: Sergey Shelukhin > Assignee: Sergey Shelukhin > Labels: BB2015-05-TBR > Attachments: HDFS-7878.01.patch, HDFS-7878.02.patch, > HDFS-7878.03.patch, HDFS-7878.04.patch, HDFS-7878.05.patch, > HDFS-7878.06.patch, HDFS-7878.patch > > > See HDFS-487. > Even though that is resolved as duplicate, the ID is actually not exposed by > the JIRA it supposedly duplicates. > INode ID for the file should be easy to expose; alternatively ID could be > derived from block IDs, to account for appends... > This is useful e.g. for cache key by file, to make sure cache stays correct > when file is overwritten. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org