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

Erik Krogen commented on HADOOP-14136:
--------------------------------------

[~manojg], so you would access the two via {{viewfs://ClusterX/}} and 
{{viewfs://ClusterY/remote}}, correct? The issue is that we want to hide the 
detail from the client of which cluster the physical data lies on. We want 
those locations to be managed by cluster admins who can update the mount table 
(in a shared config) as opposed to clients having to update their URLs and be 
aware of which cluster data resides on.

> Default FS For ViewFS
> ---------------------
>
>                 Key: HADOOP-14136
>                 URL: https://issues.apache.org/jira/browse/HADOOP-14136
>             Project: Hadoop Common
>          Issue Type: New Feature
>          Components: fs, viewfs
>            Reporter: Erik Krogen
>
> It would be useful if ViewFS had the ability to designate one FileSystem as a 
> "primary"/"default" to fall back to in the case that an entry in the mount 
> table is not found. Consider the situation when you have a mount table that 
> looks like:
> {code}
> /data -> hdfs://nn1/data
> /logs -> hdfs://nn1/logs
> /user -> hdfs://nn1/user
> /remote -> hdfs://nn2/remote
> {code}
> {{nn1}} here is being used as the primary, with a specific directory 'remote' 
> being offloaded to another namenode. This works, but if we want to add 
> another top-level directory to {{nn1}}, we have to update all of our 
> client-side mount tables. Merge links (HADOOP-8298) could be used to achieve 
> this but they do not seem to be coming soon; this special case of a default 
> FS is much simpler - try to resolve through the VFS mount table, if not 
> found, then resolve to the defaultFS.
> There is a good discussion of this at 
> https://issues.apache.org/jira/browse/HADOOP-13055?focusedCommentId=15733822&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15733822



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to