I've test with : option read-subvolume
it does not work.
I've have do tcpdump on my two server ,if i run a cp command from a client,
traffic is always to the first server in subvolume parameter, option
read-subvolume does not work in my case.
Nicolas
On Thu, Mar 19, 2009 at 12:40 PM, nicolas prochazka
<prochazka.nicolas@xxxxxxxxx> wrote:
> i understand that, but in this case, i have an other problem :
> it seems that's load balancing between subvolumes does not work very well,
> the first server in subvolumes list is very often use compare to other
> server ( in read ) = > so
> i 've big ressource network usage and this first server, not in second .
>
> nicolas
>
> On Thu, Mar 19, 2009 at 12:08 PM, Gordan Bobic <gordan@xxxxxxxxxx> wrote:
>> On Thu, 19 Mar 2009 16:25:21 +0530, Vikas Gorur <vikas@xxxxxxxxxxxxx>
>> wrote:
>>> 2009/3/19 Gordan Bobic <gordan@xxxxxxxxxx>:
>>>> On Thu, 19 Mar 2009 16:14:18 +0530, Vikas Gorur <vikas@xxxxxxxxxxxxx>
>>>> wrote:
>>>>> 2009/3/19 Gordan Bobic <gordan@xxxxxxxxxx>:
>>>>>> How does this affect adding new servers into an existing cluster?
>>>>>
>>>>> Adding a new server will work --- as and when files are accessed, new
>>>>> extended attributes will be written.
>>>>
>>>> And presumably, permanently removing servers should also work the same
>>>> way?
>>>> I'm only asking because I had a whole array of weird spurious problems
>>>> before when I removed a server and added a new server at the same time.
>>>
>>> Removing a server might not work so seamlessly, since the new client
>>> will expect smaller size extended attributes whereas the older files
>>> will have bigger ones. IIRC, this was the source of the errors you
>>> faced ("Numerical result out of range"). Fixes for this are on the
>>> way.
>>
>> Ah, OK, that makes sense. Thanks for clearing it up.
>>
>> Now if just the lockup on udev creation (root on glusterfs) in rc4 and the
>> big memory leak I reported get sorted out, I'll have a working system. ;)
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel@xxxxxxxxxx
>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>>
>
