[Gluster-users] Why does NUFA not allow mounts even from trusted peers without a subvolume?

[Michael Lampe]

Just checked nufa.c from the official 3.4.1 sources and things look very 
much different from

http://review.gluster.org/#/c/5414/2/xlators/cluster/dht/src/nufa.c

There is surely no such fallback.

-Michael

Michael Lampe wrote:
> I'm using the 3.4.1-3.el5 packages from gluster.org.
>
> Am I perhaps misinterpreting the problem?
>
> -Michael
>
> Anand Avati wrote:
>> You are probably using 3.3 or older? This has been fixed in 3.4 (
>> http://review.gluster.org/5414)
>>
>> Thanks,
>> Avati
>>
>>
>> On Wed, Dec 4, 2013 at 2:05 PM, Michael Lampe
>> <mlampe0 at googlemail.com>wrote:
>>
>>> I've installed GlusterFS on our 23-node Beowulf cluster. Each node has a
>>> disc which provides a brick for the GlusterFS volume and every node
>>> mounts
>>> this volume. The NUFA translator is ideal for the code we run and
>>> everythings works fine so far.
>>>
>>> Only problem is the frontend node, which does not have a subvolume:
>>> After
>>> I've turned on NUFA, it no longer can mount the volume. :(
>>>
>>> [2013-12-04 21:35:44.262738] E [nufa.c:641:init] 0-gv0-dht: Could not
>>> find
>>> specified or local subvol
>>> [2013-12-04 21:35:44.262766] E [xlator.c:390:xlator_init] 0-gv0-dht:
>>> Initialization of volume 'gv0-dht' failed, review your volfile again
>>> [2013-12-04 21:35:44.262783] E [graph.c:292:glusterfs_graph_init]
>>> 0-gv0-dht: initializing translator failed
>>> [2013-12-04 21:35:44.262799] E [graph.c:479:glusterfs_graph_activate]
>>> 0-graph: init failed
>>>
>>> Is there any technical reason for treating things this way? Why cannot
>>> NUFA fall back to distribute, like it does when the local subvolume
>>> has not
>>> enough free space?
>>>
>>> Or is there a better way to include a frontend node?
>>>
>>> -Michael
>>> _______________________________________________
>>> Gluster-users mailing list
>>> Gluster-users at gluster.org
>>> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>>>
>>
>