Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
MapReduce, mail # user - Question about Name Spaces…


Copy link to this message
-
Re: Question about Name Spaces…
Harsh J 2013-05-16, 05:14
Do you see viewfs mounts coming useful there (i.e. in place of
hardlinks across NSes)?

On Thu, May 16, 2013 at 3:49 AM, Michael Segel
<[EMAIL PROTECTED]> wrote:
> Actually creating links, symbolic or hard links makes sense in a couple of scenarios.
> Especially in terms of hive... ;-)
>
> So it kind of goes back to my extension of the question about that Jira (HDFS-3370) to see if its alive or just forgotten?
>
> The point is that one of the arguments against doing it didn't make sense. Creating hard links across Name Spaces.
> IMHO you'd want to create hard links within the same NN. Maybe a symbolic link across name spaces, but even then, I'm not so sure... still need to think more about the problem.
>
> On May 15, 2013, at 1:30 PM, Harsh J <[EMAIL PROTECTED]> wrote:
>
>> Namespace divides are designed with application-level separation in
>> mind. Sharing a file across namespaces does not make a whole lot of
>> sense to me.
>>
>> Anyhow, the data is on the same set of DNs, and there's HA for NN's
>> own availability (if thats really a concern), so I don't see why
>> anyone would like to _maintain_ two synced copies of files as thats
>> just data duplication when all you need is a simple path (viewfs)/URI
>> (hdfs) to access a file lying on a different NN.
>>
>> The reason you mention of metadata availability doesn't sound logical
>> - in such a case a person has to build a self failover of URIs for
>> said file, which they can simply avoid by using HDFS HA for the
>> hosting NN.
>>
>> On Wed, May 15, 2013 at 7:47 PM, Michael Segel
>> <[EMAIL PROTECTED]> wrote:
>>> Quick question...
>>> So when we have a cluster which has multiple namespaces (multiple name nodes) , why would you have a file in two different namespaces?
>>>
>>>
>>
>>
>>
>> --
>> Harsh J
>>
>

--
Harsh J