Gluster users - Nov 2010 - Asymmetrical storage capacity on Glusterfs bricks

Has anybody tried asymmetrical storage capacity on Glusterfs bricks?

For example, I have my 6 servers configured as mirrored and distributed.

Could I add storage to just one mirror pair and make it part of the backend
storage for just those servers?

I thought I read about this somewhere before on the list, but I can't seem
to find it.

Thanks,

James Burnash, Unix Engineering

DISCLAIMER:
This e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or confidential
information. If you are not the intended recipient of this e-mail, you are
hereby notified that any dissemination, distribution or copying of this e-mail,
and any attachments thereto, is strictly prohibited. If you have received this
in error, please immediately notify me and permanently delete the original and
any copy of any e-mail and any printout thereof. E-mail transmission cannot be
guaranteed to be secure or error-free. The sender therefore does not accept
liability for any errors or omissions in the contents of this message which
arise as a result of e-mail transmission.
NOTICE REGARDING PRIVACY AND CONFIDENTIALITY Knight Capital Group may, at its
discretion, monitor and review the content of all e-mail communications.
http://www.knight.com

On 11/15/2010 12:55 PM, Burnash, James wrote:
> Has anybody tried asymmetrical storage capacity on Glusterfs bricks?
>
> For example, I have my 6 servers configured as mirrored and distributed.
>
> Could I add storage to just one mirror pair and make it part of the backend
storage for just those servers?
>
> I thought I read about this somewhere before on the list, but I can't
seem to find it.
>
> Thanks,
>
> James Burnash, Unix Engineering
>
> DISCLAIMER:
> This e-mail, and any attachments thereto, is intended only for use by the
addressee(s) named herein and may contain legally privileged and/or confidential
information. If you are not the intended recipient of this e-mail, you are
hereby notified that any dissemination, distribution or copying of this e-mail,
and any attachments thereto, is strictly prohibited. If you have received this
in error, please immediately notify me and permanently delete the original and
any copy of any e-mail and any printout thereof. E-mail transmission cannot be
guaranteed to be secure or error-free. The sender therefore does not accept
liability for any errors or omissions in the contents of this message which
arise as a result of e-mail transmission.
> NOTICE REGARDING PRIVACY AND CONFIDENTIALITY Knight Capital Group may, at
its discretion, monitor and review the content of all e-mail communications.
http://www.knight.com
>
>
>
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
James -
    It works out of the box. We do have a best practice around 
asymmetrical storage servers that will improve performance over just 
expanding the mount -

Ideally each storage brick [1] in a Gluster cluster will be the same 
size. If bricks differ in size Gluster uses stub files to maintain the 
Elastic Hashing Algorithm model, the use of stub files [2] for 
redirection will negatively impact performance. LVM2 is the easiest way 
to create bricks that don't occupy an entire device. Using LVM2 offers 
several advantages, by creating more smaller LVs if a file system needs 
to be fsck'ed the process is faster. Snapshots and clones are also 
compatible with Gluster.


[1] A brick is the combination of a server and a filesystem, ie 
server1:/dev/vg1/lv1 and server1:/dev/vg1/lv2 are both bricks.
[2] http://en.wikipedia.org/wiki/Stub_file

Please let me know if you have any other questions.

Thanks,

Craig

-->
Craig Carl
Senior Systems Engineer
Gluster