Distribute translator and differing brick sizes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 27, 2009 at 1:23 AM, Raghavendra G <raghavendra at zresearch.com>wrote:

> Hi,
>
> On Tue, Jan 27, 2009 at 3:27 AM, Sean Davis <sdavis2 at mail.nih.gov> wrote:
>
>> If I am putting together several volumes of varying sizes using
>> distribute, what type of load balancing should I expect?  I understand
>> hashing and it sounds like if the disk fills, then it is not used, but can I
>> use ALU scheduler to cut things off before the disk becomes full to allow
>> for growth of directories and files?  How are people approaching this?
>
>
> Distribute,  does not have any schedulers. The hashing as of now is sort of
> static in the sense that if the disk becomes full, further creation of files
> which happen to be scheduled to that node fail. Future versions of
> distribute will reschedule the files to different nodes.
>
>

Thanks, Raghavendra.

So, it sounds like Distribute is problematic for any inhomogeneous file
system (where bricks are of different sizes) or for systems that are not
meant as "archival" (that is, write once, read many).  I understand that for
boatloads of small files, performance is improved over unify by using
distribute, but it sounds like unify is currently the better option for my
situation.

Is it worthwhile pointing out these details on the wiki somewhere?  The
website appears to suggest that unify/schedulers are "legacy" systems, which
implies that they are inferior to rather than an alternative to Distribute.
However, in my situation, it appears that Unify is the only viable solution.

Thanks for the help.

Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zresearch.com/pipermail/gluster-users/attachments/20090127/3cf2322e/attachment.htm 


[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux