Re: Setting up a new AFR, but using one preexisting directory

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

 



On Wed, Apr 30, 2008 at 2:04 PM, Brandon Lamb <brandonlamb@xxxxxxxxx> wrote:
> I cant find the mail, I noticed it a few days ago, someone mentioned
> something about setting the file attributes to 3? Does that make
> sense?
>
> Anyway, it sounded like what may have been giving me some grief last
> time I set up a 2 server afr config. On one server I had my web data,
> and on the other i had a new blank folder. I thought by setting up
> gluster (using the existing dir on one, and a new empty dir on the
> other) that by doing the find () trick it would sync all the files,
> but is this maybe not true?
>
> I bring this up for 2 reasons, one to have it answered, and two
> because maybe this shoud be on the wiki somewhere.
>
> When setting up a new afr, should you start with 2 empty directories
> and then copy your files to the glusterfs mount, or should you do an
> rsync and then do the set attributes to 3 thing (could someone give a
> little more detail or correct my language on this?).
>
> Hopefully I am making some sense with my question, Im not totally
> clear on it myself.
>
> thanks!

http://www.gluster.org/docs/index.php/Automatic_File_Replication_%28Mirror%29_across_Two_Storage_Servers

Maybe this page could be worked up a little more with some information on this?

I apologize for not knowing, Im not sure who all does the examples or
if its one person or what. Could the person(s) in charge of the
examples or maybe just this one add more to this though?

It may seem redundant to those that are comfortable configuring the
bricks, but myself, I dont fully understand what should go where, what
order. I understand this is a hard question to answer though because
of how configurable glusterfs can be.

So my request I guess is specific to a 2 machine, server side afr with
many clients config example(s).

Maybe start with the basic one that is there, then add a few more
examples with how you might tune it with performance translators and
such. It would just save a little time compared to the trial and error
method.




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

  Powered by Linux