[Gluster-users] glusterfs performance issues

[Stephan von Krawczynski]

On Tue, 8 Jan 2013 08:01:16 -0500
Whit Blauvelt <whit.gluster at transpect.com> wrote:

> On Tue, Jan 08, 2013 at 01:11:24PM +0100, Stephan von Krawczynski wrote:
> 
> > Nobody besides you is talking about timestamps. I would simply choose an
> > increasing stamp, increased by every write-touch of the file.
> > In a trivial comparison this assures you choose the latest copy of the file.
> > There is really no time needed at all, and therefore no time synchronisation
> > issues.
> 
> So rather than the POSIX attribute of a time stamp, which is I'm pretty sure
> what we all thought you were talking about, you're asking for a new
> xattribute? And you want that to be simply iterative? Okay, so in a
> split-brain, a file gets touched 5 times on one side, and actually written
> to just once, not touched at all, on the other. Then the system's brought
> back together. Your "trivial comparison" will choose the wrong file version.

What an dead-end argument. _Nothing_ will save you in case of a split-brain.
Lets clarify that a split-brain is a situation where your replication unit is
teared into bricks and these used independently from each other. There is no
way at all to join such a situation again regarding equal files being written
to. You cannot blame a versioning for having another really bad conceptional
problem. Since there is no automated solution to a split brain you can either
decide to give the user access to two different file versions, none of which
has the original file name to prevent irritation or live with lost data by
choosing one of the available file versions. 
Lets spell it this way: either you want maximum availability and accept a
split brain in worst case (indeed very acceptable in case of read-only data),
or you prevent split brain and accept downtime of _some_ of the clients by
choosing which brick is master in this special case.
 
> That's the thing about complex systems. Trivial solutions are usually both
> simple and wrong. Some work most of the time, but there are corner cases. As
> we see with Gluster even complex solutions tend to have corner cases; but at
> least in complex solutions the corners can be whittled down.

Can they? I'd rather say if it is non-trivial it is broken most of the time.
Ask btrfs for confirmation.
 
> Regards,
> Whit

-- 
Regards,
Stephan