[
https://issues.apache.org/jira/browse/HDFS-7878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Douglas updated HDFS-7878:
--------------------------------
Attachment: HDFS-7878.13.patch
Trying another iteration. I think this addresses the outstanding feedback and
reflects the consensus.
This does not extend {{FileStatus}} and should be compatible with 3.0.0-beta1.
Rather than adding {{open(FileStatus)}} this adds {{open(PathHandle)}} with an
{{getPathHandle(FileStatus, Option...)}} pattern for handle parameters. The
standard set of options is a mix of two flags, allowing the caller to specify
whether the {{PathHandle}} remains valid after the file is modified or if the
file is moved. The implementation defines a few utility methods to make the
semantics clearer and to support {{Stream}} APIs easing bulk conversion.
Implementations can extend the set of options with bespoke semantics.
This patch updates the specification and contract tests. The current
implementation in HDFS does not detect content changes, so it only passes the
{{reference()}} check that resolves the {{PathHandle}} even if the file is
moved and/or changed (i.e., open by inodeid).
[~mackrorysd], [~andrew.wang], [~ste...@apache.org], [~anu] Could you take a
look?
To support creating a {{PathHandle}} from a {{LocatedFileStatus}}, I'll open a
followup JIRA to implement one of [~ste...@apache.org]'s ideas, to make
{{HdfsFileStatus}} extend {{LocatedFileStatus}} and fold the functionality of
{{HdfsLocatedFileStatus}} into its supertype.
> 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.07.patch, HDFS-7878.08.patch,
> HDFS-7878.09.patch, HDFS-7878.10.patch, HDFS-7878.11.patch,
> HDFS-7878.12.patch, HDFS-7878.13.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
