<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 09/17/2009 11:52 PM, Michael Cassaniti wrote:
<blockquote
cite="mid:c5e56c030909172052t279e460ag9a076fb7a8deadaa@mail.gmail.com"
type="cite">
<div class="gmail_quote"><br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
</div>
This could mean that GlusterFS is too lax with regard to consistency
guarantees. If files can appear in the background, and magically be
shown - this indicates that GlusterFS is not enforcing use through the
mount point, which introduces the potential for inconsistent or faulty
results. You are asking for it to guess what you want, without seeing
that what you are asking for is incompatible with provisions for any
guarantee of a consistent view. That "it works" is actually more
concerning to me that justifying over your position. To me it says it's
one more potential problem that I might hit in the future. A file that
should be removed magically re-appears - how is this a good thing?<br>
</blockquote>
<div><br>
I guess the last question is a good one for the developers. If the
required extended attributes do not exist on the backend, should the
files/directories (excluding the root directory) show in a stat() call?
That may be a blessing or curse for new users, especially when this
post has been going on about automatic creation of extended attributes
for pre-existing files in the backend. <br>
</div>
</div>
</blockquote>
<br>
Yep - exactly. Personally, I prefer correct behaviour over some
one-time benefit of being able to mount on top of existing file store
and have it do its best to automatically create extended attributes or
treat files without extended attributes as files that exist.<br>
<br>
When reading the GlusterFS replication description - it seemed like
they discussed what happens if a node goes down *during* the unlink(),
but they didn't specifically cover what happens if the node is down
before and after the unlink(), but then brought back up some time
later. One interpretation suggested to me that the journal would not
hang around, and the file would be treated as gone from all "up" nodes,
and then when the later node is brought back up, the file shows up as
existing on only one node, and the self-heal would kick in and
replicate the file as if it still exists. I didn't find the time to
test this exact scenario yet, though...<br>
<br>
Cheers,<br>
mark<br>
<br>
<pre class="moz-signature" cols="72">--
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>
</body>
</html>