<div dir="ltr">Inline<br><br><div class="gmail_quote">On Sun, Aug 22, 2010 at 4:41 PM, Amos Shapira <span dir="ltr"><<a href="mailto:amos.shapira@gmail.com">amos.shapira@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 22 August 2010 23:22, Oleg Goldshmidt <<a href="mailto:pub@goldshmidt.org">pub@goldshmidt.org</a>> wrote:<br>
><br>
> On Sun, Aug 22, 2010 at 2:25 PM, Amos Shapira <<a href="mailto:amos.shapira@gmail.com">amos.shapira@gmail.com</a>> wrote:<br>
><br>
> > We are a little concerned about the situation of two guests mounting<br>
> > the ext3 and starting to manipulate the sqlite files on it in<br>
> > parallel.<br>
><br>
> I think you should be *very* concerned about the situation where 2<br>
> guests mount an ext3 partition and start to manipulate files<br>
> *sequentially*. It looks like you *are* concerned (rightly), since you<br>
> wrote that only one client *mounts* the partition at a time.<br>
<br>
</div>Yes. But apart from hoping that RHCS does its job right, there is<br>
nothing preventing other guests from mounting the same partition in<br>
parallel.<br>
<div class="im"><br></div></blockquote><div>Of course there is - LUN masking. Its purpose is exactly this. You expose the LUN *only* to the nodes which require direct access to it. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
><br>
> > Another option was to allow all guests to mount the file<br>
> > system read/write but carefully configure each guest to "own"<br>
> > different files or directories of sqlite files on the FS.<br>
><br>
> What if one starts, e.g., creating files or appending content to<br>
> existing files (and allocating new blocks, etc., in the process)? The<br>
> other clients won't be aware of it.<br>
<br>
</div>That's why we looked at cluster-aware file systems in form of GFS but<br>
decided the performance hit is too great to go with it. A brief look<br>
at OCFS installation steps gave an impression that it isn't trivial or<br>
well supported on CentOS 5.<br></blockquote><div>Incorrect impression. Less than 5 minutes work, being extra slow, with coffee included. Simple enough? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
><br>
> I admit I have not thought long and hard about it, but it sounds<br>
> dangerous to me.<br>
<br>
</div>It is. As was pointed out earlier in this thread - a large part of the<br>
"file system" is about how the file system module "caches" information<br>
in memory and synchronises it on the disk. If it's not a cluster-aware<br>
file system then parallel mounting is equivalent to opening the LV or<br>
device by an application and randomly starting to write data on it.<br></blockquote><div>True. But cluster-aware FS should be considered carefully. For some purposes, they ease management. For some others, they complicate it.</div>
<div>GFS has always been misunderstood by me. It has little benefits, and major drawbacks. Can't see any reason to use it, from the existing variety of clustered FS around.</div><div><br></div><div>Ez</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers,<br>
<font color="#888888"><br>
--Amos<br>
</font></blockquote></div><br></div>