[Gluster-users] GlusterFS 3.1.3 is available

Mohit Anchlia mohitanchlia at gmail.com
Fri Mar 18 17:44:50 UTC 2011


Thanks a lot! It makes me feel better. But is it possible to give a
very high level as to how it will be O(1)? If hashing is changed how
can it still be effective in the way that gluster know to go to the
right node and fetch the file without asking each node if they have
the file?

On Fri, Mar 18, 2011 at 10:38 AM, Amar Tumballi <amar at gluster.com> wrote:
> In best case distribute algorithm is O(1) and in case if there is a linkfile
> then it will be O(2) (which is treated as O(1) itself as per algorithm
> complexities). (and is not 'every' node as you mentioned), hence it won't be
> a big impact
> Regards,
> Amar
> On Fri, Mar 18, 2011 at 10:57 PM, Mohit Anchlia <mohitanchlia at gmail.com>
> wrote:
>>
>> Thanks! Does linkfile concept cause any performance degradation since
>> now it will need to request every node if file exists or not?
>>
>> On Fri, Mar 18, 2011 at 10:19 AM, Amar Tumballi <amar at gluster.com> wrote:
>> > Hi Mohit,
>> > Sorry for the delay.. answer inline..
>> >>
>> >> Thanks for getting this release out. I was going through the release
>> >> and didn't quite understand "fix layout by issuing re-balance" means.
>> >> Does it mean if server is added or removed and then new files created
>> >> in "existing" directory will not hash accross all the nodes (including
>> >> new nodes)?
>> >>
>> >
>> > Currently, the hashing range/layout is different per directory, and is
>> > set
>> >  during the mkdir(). Hence, when a new node is added, new files created
>> > under existing directory will not be hashed to new nodes. that is
>> > handled by
>> > issuing a 'gluster rebalance' command.
>> > And when there is a 'remove-brick' command, the existing hash layout in
>> > the
>> > directory will miss some ranges which belongs to those new nodes, hence
>> > again, you would need 'gluster rebalance' which does fix the layout
>> > issues.
>> >
>> >>
>> >> And another question is it necessary to run "migrate-data" after
>> >> running "fix-layout"? If answer is "no" then after fixing layout
>> >> (fix-layout) wouldn't it confuse gluster hashing algorigthm in anyway
>> >> when accessing existing files?
>> >>
>> >
>> > answer to first part of the question is 'no' (ie, you don't need to run
>> > 'migrate-data' always after 'fix-layout'). Internally the hashing
>> > algorithm
>> > is fool proof to handle it. We have a concept called linkfile which does
>> > this.
>> > Regards,
>> > Amar
>> >
>
>



More information about the Gluster-users mailing list