[
https://issues.apache.org/jira/browse/HDFS-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731640#action_12731640
]
Sanjay Radia commented on HDFS-487:
-----------------------------------
It would be useful to articulate the various use cases for the file id plus the
mapping data structures that would be needed.
Dhruba has given one use case.
Another one is that if we propagate the fileId to the DNs than one can
reconstruct files from blocks (though without their file names.)
Hard links is another use case though I am not a fan of hard links.
Others?
Would fileIds simplify things inside the NN?
Mappings:
Currently, inside a NN we have mappings from filename->inode,, inode->blocks.
To make the file id useful we would have to add a mapping from fileId->inode.
This mapping would use up memory which is scarce inside a NN, but perhaps it
could replace
other data structures.
Wouldn't one need the fileId to inode->blocks for puggable block placement
policies?
> HDFS should expose a fileid to uniquely identify a file
> -------------------------------------------------------
>
> Key: HDFS-487
> URL: https://issues.apache.org/jira/browse/HDFS-487
> Project: Hadoop HDFS
> Issue Type: New Feature
> Reporter: dhruba borthakur
> Assignee: dhruba borthakur
> Attachments: fileid1.txt
>
>
> HDFS should expose a id that uniquely identifies a file. This helps in
> developing applications that work correctly even when files are moved from
> one directory to another. A typical use-case is to make the Pluggable Block
> Placement Policy (HDFS-385) use fileid instead of filename.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
