So, as I'm trying to write an updated config, I got a little more confused.
If the *:2 replicates only the first 2 bricks listed in the subvolume line
(current implementation), then the bricks 3,4,5,etc are not utilized.
If I specify *:2 and only have 1 brick, where does the replicas reside?
If I only have 1 brick listed in each subvolume, and if I say repliate *:2,
then wouldn't AFR need 2 bricks listed in the subvolumes line to replicate
the two copies to, but I only listed 1.
Thanks in advance for clearing up my confusion
From: "Amar S. Tumballi" <amar@xxxxxxxxxxxxx>
To: "DeeDee Park" <deedee6905@xxxxxxxxxxx>
CC: gluster-devel@xxxxxxxxxx
Subject: Re: core bt - client_write_cbk1
Date: Fri, 13 Jul 2007 10:21:23 +0530
yes, this config should be fine.
Yes, we are aware that even configs are wrong we should not segfault. We
have fixed the bug reported by you.. thanks.
-amar
On 7/13/07, DeeDee Park <deedee6905@xxxxxxxxxxx> wrote:
I was doing different testing, eg AFR :2, and at the time thought the :1
would be a quick way
to turn off AFR without having to move my subvolumes command around.
I originally had bricks, unify (subvolumes listed 5 bricks), and then AFR.
I
was told
that AFR has to come before the unify, so that is why I swapped it around.
Based on your comments, I can now see that unify would be useless above
AFR,
and
now that documentation about multiple AFR over each brick is making some
sense.
So, should I have something like the following as the correct config?
brick1
brick2
brick3
afr1
subvolumes brick1
afr2
subvolumes brick2
afr3
subvolumes brick3
unify
subvolume afr1 afr2 afr3
I know you don't have the config checking yet, but one thing, even if the
user config is wrong
or screwy, program should not core dump.
>From: "Amar S. Tumballi" <amar@xxxxxxxxxxxxx>
>To: "DeeDee Park" <deedee6905@xxxxxxxxxxx>
>CC: gluster-devel@xxxxxxxxxx
>Subject: Re: core bt - client_write_cbk1
>Date: Thu, 12 Jul 2007 10:59:04 +0530
>
>DeeDee,
>
>Thanks for reporting bug, but actually this config has afr enabled. My
few
>doubts after seeing your config file.
>
>You wrote this config just to test afr/unify? or you had any idea while
>writing them, because there are two things i can notice.
>
>* afr has 5 child nodes, but it creates all the files in just first
child
>node (replicate *:1)
>* unify has just one subvolume, which means the unify translator is
>useless.
>(unless otherwise, you wanted a persistant inode from namespace).
>
>-amar
>
>On 7/12/07, DeeDee Park <deedee6905@xxxxxxxxxxx> wrote:
>>
>>client config & core attached.
>>
>>_________________________________________________________________
>>http://newlivehotmail.com
>>
>>_______________________________________________
>>Gluster-devel mailing list
>>Gluster-devel@xxxxxxxxxx
>>http://lists.nongnu.org/mailman/listinfo/gluster-devel
>>
>>
>>
>
>
>--
>Amar Tumballi
>http://amar.80x25.org
>[bulde on #gluster/irc.gnu.org]
_________________________________________________________________
Local listings, incredible imagery, and driving directions - all in one
place! http://maps.live.com/?wip=69&FORM=MGAC01
--
Amar Tumballi
http://amar.80x25.org
[bulde on #gluster/irc.gnu.org]
_________________________________________________________________
http://im.live.com/messenger/im/home/?source=hmtextlinkjuly07
