[
https://issues.apache.org/jira/browse/HDFS-7878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154865#comment-16154865
]
Chris Douglas edited comment on HDFS-7878 at 9/6/17 6:25 AM:
-------------------------------------------------------------
Thanks, [[email protected]]. Addressed other comments. This still needs more
tests, so if everyone generally agrees with the direction I'll start on that.
bq. L108: any limit on buffer size here? I'm just worrying about malicious DoS
against client/server RAM
Would 1MiB be a reasonable limit to start? It's an unreasonable size for a
handle, but it may be a reasonable, fixed limit.
To support HDFS-9806, we also need a reference for {{open}} i.e., not just
opening the file specified via inode, but also that its underlying data are
unchanged. That can be followup, or part of this issue.
was (Author: chris.douglas):
bq. L108: any limit on buffer size here? I'm just worrying about malicious DoS
against client/server RAM
Would 1MiB be a reasonable limit to start? It's an unreasonable size for a
handle, but it may be a reasonable, fixed limit.
Addressed other comments. This still needs more tests, so if everyone generally
agrees with the direction I'll start on that.
To support HDFS-9806, we also need an "exact" match for {{open}} i.e., not just
opening the file specified, but also that its underlying data are unchanged.
> 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.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: [email protected]
For additional commands, e-mail: [email protected]
