Gluster users - Jan 2009 - Distribute translator and differing brick sizes

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?

Thanks,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20090126/0a4548a2/attachment.html>

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,
> Sean
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
>
>

-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20090127/6f41de9c/attachment.html>

On Tuesday 27 January 2009 01:27:42 Sean Davis 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? 
To implement artificial quotas, I've created multiple loopback filesystems 
with unit sizes, and shared those with AFR.  This is far from optimal, but it 
does mean that I can be sure that the volumes are a the same size.  
Conceivably, they can be enlarged if they run out of space.  LVM would be 
just as good/bad, but I don't want to take the machines down to resize 
partitions.

If glusterfs implemented soft quotas I would use that rather -- even though 
quotas are metadata.

&:-)

At 10:34 PM 1/26/2009, Andrew McGill wrote:
>On Tuesday 27 January 2009 01:27:42 Sean Davis 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?
>
>To implement artificial quotas, I''ve created multiple loopback
filesystems
>with unit sizes, and shared those with AFR.  This is far from optimal, but
it
>does mean that I can be sure that the volumes are a the same size.
>Conceivably, they can be enlarged if they run out of space.  LVM would be
>just as good/bad, but I don''t want to take the machines down to
resize
>partitions.
aren''t quotas enforced on the server side if they''re enabled
there?

I''m not using quotas so I can''t test this for you, but
logically this
seems like it would work since gluster ultimately is bound by the 
rules of it''s underlying filesystems.

I''m just not sure how it would behave if someone tries to append or 
write a file that would cause an over-quota problem and, in the case 
of HA/AFR what would happen if quotas were turned on on one server 
and not on another?

hopefully someone will calarify so we''ll both know :)

On Tuesday 27 January 2009 13:38:14 Keith Freedman
wrote:
> At 10:34 PM 1/26/2009, Andrew McGill wrote:
> >On Tuesday 27 January 2009 01:27:42 Sean Davis 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?
> >
> >To implement artificial quotas, I've created multiple loopback
filesystems
> >with unit sizes, and shared those with AFR.  This is far from optimal,
but
> > it does mean that I can be sure that the volumes are a the same size.
> > Conceivably, they can be enlarged if they run out of space.  LVM would
be
> > just as good/bad, but I don't want to take the machines down to
resize
> > partitions.
>
> aren't quotas enforced on the server side if they're enabled there?
>
> I'm not using quotas so I can't test this for you, but logically
this
> seems like it would work since gluster ultimately is bound by the
> rules of it's underlying filesystems.
>
> I'm just not sure how it would behave if someone tries to append or
> write a file that would cause an over-quota problem and, in the case
> of HA/AFR what would happen if quotas were turned on on one server
> and not on another?
>
> hopefully someone will calarify so we'll both know :)
Just to be clear, I don't want per-user quotas, but an artificial limit on
the
amount of disk space that a glusterfs brick will use -- ie. a false "disk 
free" for the glusterfs files.  

In my case, I can spare 200Mb on a few machines for glusterfs files.  There is 
250Mb of space free.  I don't want to use the last 50Mb for glusterfs but
for
important mail loops.  Since the AFR code only considers the disk free on the 
first brick, I suppose I could implement what I'm doing by having a loopback
filesystem on the first brick, and using plain files as part of the regular 
filesystem on the others.... (now that's not such a bad idea, you know)....

&:-)