<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I'm sorry you took that email as an "I'm always right" sort of
thing. You were telling a user that things were a certain way and
for the majority of users that I encounter on a daily basis, it's
just not true. I wanted to set the record straight so that user can
make a properly informed decision. If you'd put your absolutes in a
context of "I tried to do it this way but it didn't work for me",
then I wouldn't have had a leg to stand on.<br>
<br>
I hang out on the IRC and help people all day long for the last
couple of years. I've seen many more people with positive
experiences than negative ones. When something doesn't work as
designed, I always encourage bug reports. If you have found bugs,
please report them. I just did a search and can't find any that
you're attached to. There are a whopping 34 open bugs for
geo-replicate and 14 of those are feature requests. Of the remaining
20, 5 haven't been fixed yet. That doesn't look like "it's really
buggy" to me (looking at geo-replication because that's the tool
designed to be "distributed to more than one place" which is what I
believe we're discussing).<br>
<br>
The reason I, and most of the people that I work with that also have
successfully used GlusterFS, don't update the docs to tell you how
to do it successfully is because we just followed the docs and it
worked. There are, indeed, people for whom that's not true. There
have been, on occasion, people even in the IRC channel that had
problems that were so far outside the norm that we couldn't help
them. Obviously I can't tell you why they have problems because we
couldn't figure out their problem. Most of the people who do have
problems missed at least one step in the installation process as
documented.<br>
<br>
If you've found a bug but are having troubles isolating it, feel
free to ask for help here or on the IRC channel (#gluster on
freenode). I love finding bugs so we can all have a better tool to
use.<br>
<br>
<div class="moz-cite-prefix">On 10/22/2012 07:55 AM, Israel Shirk
wrote:<br>
</div>
<blockquote
cite="mid:CAF5SWt5JdHe2whzYH=5RevQ0UnV7nzUT3OKfuhXOw0z0jwYrZQ@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<span>On 10/21/2012 02:18 PM, Israel Shirk wrote:</span><br>
<span>> Haris, try the NFS mount. Gluster typically triggers
healing through</span><br>
<span>> the client, so if you skip the client, nothing heals.</span><br>
<span>Not true anymore. With 3.3 there's a self-heal daemon that
will handle</span><br>
<span>the heals. You do risk reading stale data if you don't read
through the</span><br>
<span>client though.</span><br>
<span><br>
</span>
<div>It's not going to trigger this by writing to the brick
itself, and doing 'ls -l' or stat is kind of a mess.</div>
<div><span><br>
</span></div>
<div><span>> The native Gluster client tends to be really
@#$@#$@# stupid. It'll</span><br>
<span>> send reads to Singapore while you're in Virginia (and
there are bricks</span><br>
<span>> 0.2ms away),</span><br>
<span>False. The client will read from the first-to-respond.
Yes, if Singapore</span><br>
<span>is responding faster than Virginia you might want to
figure out why</span><br>
<span>Virginia is so overloaded that it's taking more than 200ms
to respond,</span><br>
<span>but really that shouldn't be the case.</span></div>
<div><br>
</div>
<div>Totally agree. Should not be the case. Wish it was false.
But when it suddenly sends EVERYTHING to Singapore from
Virginia, not touching the servers in Virginia AT ALL, and you
can mount them using NFS and it works great, I gotta point my
finger at the client. You can disagree however much you want,
but I'm talking from very frustrating experiences here.</div>
<div><br>
<span>> then when healing is needed it will take a bunch of
time to do that,</span><br>
<span>> all the while it's blocking your application or web
server, which</span><br>
<span>> under heavy loads will cause your entire application
to buckle.</span><br>
<span>False. 3.3 uses granular locking which won't block your
application.</span></div>
<div><br>
</div>
<div>Blocking your application as in, taking so many file
descriptors due to lag that the application runs out of file
descriptors or connections and locks up.</div>
<div><br>
<span>> The NFS client is dumb, which in my mind is a lot
better - it'll just</span><br>
<span>> do what you tell it to do and allow you to compensate
for connectivity</span><br>
<span>> issues yourself using something like Linux-HA.</span><br>
<span>The "NFS client" is probably more apt than you meant. It
is both</span><br>
<span>GlusterFS client and NFS server, and it connects to the
bricks and</span><br>
<span>performs reads and self-heal in exactly the same way as
the fuse client.</span></div>
<div><br>
</div>
<div>It works, where the native Gluster client wakes you up for
hours in the middle of the night. You can argue about
internals, I'm just saying one works, the other fails miserably.</div>
<div><br>
<span>></span><br>
<span>> You have to keep in mind when using gluster that 99%
of the people</span><br>
<span>> using it are running their tests on a single server
(see the recent</span><br>
<span>> notes about how testing patches are only performed on
a single server),</span><br>
<span>False. There are many more testers than that, most of
which are outside</span><br>
<span>of the development team.</span></div>
<div><br>
</div>
<div>You are always right and I am always wrong. Congratulations
:)</div>
<div><br>
</div>
<div>I'm simply saying that I keep hearing that Gluster is
supposed to work great on distributed applications (as in
distributed to more than one place), but the reality of the
situation is that it's really buggy and nobody is willing to
acknowledge it. There are big problems with using Gluster in
this way, and I can't see that being the case when it's being
tested for this. If you're having better luck with it in a
high-traffic production environment, by all means update the
docs so others don't have to go through the downtime that
results from Gluster's undocumented issues.</div>
<div><br>
<span>> and most applications don't distribute or mirror to
bricks more than a</span><br>
<span>> few hundred yards away. Their idea of
geo-replication is that you</span><br>
<span>> send your writes to the other side of the world
(which may or may not</span><br>
<span>> be up at the moment), then twiddle your thumbs for a
while and hope it</span><br>
<span>> gets back to you. So, that said, it's possible to
get it to work, and</span><br>
<span>> it's almost better than lsyncd, but it'll still make
you cry periodically.</span><br>
<span>></span><br>
<span>> Ok, back to happy time :)</span><br>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gluster-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a>
<a class="moz-txt-link-freetext" href="http://supercolony.gluster.org/mailman/listinfo/gluster-users">http://supercolony.gluster.org/mailman/listinfo/gluster-users</a></pre>
</blockquote>
<br>
</body>
</html>