[Gluster-users] GlusterFS 3.1.3 is available
amar at gluster.com
Fri Mar 18 17:38:23 UTC 2011
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
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
> > 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
> > issuing a 'gluster rebalance' command.
> > And when there is a 'remove-brick' command, the existing hash layout in
> > directory will miss some ranges which belongs to those new nodes, hence
> > again, you would need 'gluster rebalance' which does fix the layout
> >> 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
> > is fool proof to handle it. We have a concept called linkfile which does
> > this.
> > Regards,
> > Amar
More information about the Gluster-users