hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-7878) API - expose an unique file identifier
Date Mon, 04 Sep 2017 12:12:00 GMT

    [ https://issues.apache.org/jira/browse/HDFS-7878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152542#comment-16152542
] 

Steve Loughran commented on HDFS-7878:
--------------------------------------

Coming together nicely

h4. RawPathHandle 

* L108: any limit on buffer size here? I'm just worrying about malicious DoS against client/server
RAM

h4. filesystem.md

L104: review spelling; maybe make a MUST throw, it's a new feature after all.

L179: back-quote all types in the para


L720: I've never come across the word "prenominate" before, looks like the US version of "aforementioned".
Need something globally understood, e.g. "declared previously".


L729: 

{code}
result = FSDataInputStream(0, FS.Files'[p'])
{code}

h4. AbstractContractOpenTest

L191: We should have {{ContractTestUtils}} call for rename(), if not, time to add one. 
L192: {{ContractTestUtils.assertPathDoesNotExist}}

HDFS code is for HDFS team to review. Do make sure it can handle the condition: new API call
without PathHandle bytes, with a test creating {{HdfsPathHandle}} for this.



> 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.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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org


Mime
View raw message