On Tue, May 6, 2008 at 9:45 PM, Derek Price <derek@xxxxxxxxxxx> wrote: > Krishna Srinivas wrote: > > > > > > > Is this an issue in server-side-only AFR? I have two servers which > are also > > > > clients of themselves, and they both list their local subvolume first > and > > > > remote subvolume second. Is this a problem? What are the possible > > > > consequences of this? > > > > > > It will be a problem. The "first" subvol is always the "lock" server. > > > Consider a case where you are creating a file simultaneously > > > on two clients, only one of them should succeed. If AFR's > > > subvols order are not same, chances are that both client > > > returns success for file creation with same name. > > > > > > > Hence you have "option read-subvlume" to speeden the > > read() calls so that it can be done from local subvol. > > > > So, what happens if the "lock" server is the one that goes down? Will that > render the whole AFR cluster inoperable, at least for writes? > If first server is down, the second one is tried and so on. The cluster remains operable. Krishna > Why not arrange some sort of voting system for AFR locks, where no specific > server, but rather half of the listed servers (maybe the first server listed > gets an extra vote in the case of an even number of servers) have to agree > to assign the lock (and increment the version # without receiving the data). > Then writes could also be done locally and synchronized at leisure. > > Derek > -- > Derek R. Price > Solutions Architect > Ximbiot, LLC <http://ximbiot.com> > Get CVS and Subversion Support from Ximbiot! > > v: +1 248.835.1260 > f: +1 248.246.1176 >
