<br><br><div class="gmail_quote">On Sat, Apr 3, 2010 at 6:22 PM, Stephan von Krawczynski <span dir="ltr"><<a href="mailto:skraw@ithnet.com">skraw@ithnet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Sat, 3 Apr 2010 17:02:38 +0400<br>
Raghavendra G <<a href="mailto:raghavendra@gluster.com">raghavendra@gluster.com</a>> wrote:<br>
<br>
> On Fri, Apr 2, 2010 at 5:49 PM, Stephan von Krawczynski <<a href="mailto:skraw@ithnet.com">skraw@ithnet.com</a>>wrote:<br>
><br>
> > On Fri, 02 Apr 2010 14:41:36 +0100<br>
> > Gordan Bobic <<a href="mailto:gordan@bobich.net">gordan@bobich.net</a>> wrote:<br>
> ><br>
> > > On 02/04/2010 12:32, Olivier Le Cam wrote:<br>
> > ><br>
> > > > Following to a recent talk on the IRC channel, it came to my mind that<br>
> > > > caching lookups could (in this particular situation) greatly improve<br>
> > the<br>
> > > > performances.<br>
> > ><br>
> > > Maybe some of the devs can explain whether this is plausible, but I<br>
> > > somewhat doubt it. You would lose the integrity guarantees.<br>
> ><br>
> > If you're talking of data integrity here I doubt that it is there at all.<br>
> > Yesterday I checked a configuration with 2.0.9 replication and 3 clients<br>
> > with<br>
> > iocache. I found out that if I edit an ascii file on one client and save it<br>
> > back being the same size as before, another client still sees the old file<br>
> > content. I checked the servers and found that they all contained the<br>
> > correct<br>
> > new file version. So the data integrity is broken anyway when using iocache<br>
> > on<br>
> > clients<br>
> ><br>
><br>
> This is quite expected, since the client on which the data is being read has<br>
> cached the data. io-cache has cache-timeout option which can be tuned to<br>
> force the clients to check whether the file has changed on server after<br>
> configured time intervals.<br>
><br>
> However also please note that, if the file is being modified and read from<br>
> the same client, this issue would/should not have happened.<br>
<br>
</div></div>To make this point clear:<br>
There is no issue modifying and reading a file on the very same client.<br>
There is an issue modifying on client1 and reading on client2, and it is not<br>
solvable via io-cache options like cache-timeout. As you can see in my<br>
previous posts the cache-timeout is set to 1 (second). It is obvious that I<br>
was not able to check within one second on two interactive consoles.<br>
So I cannot tell you the influence cache-timeout really has, but obviously it<br>
does not work as you expected. The io-cache stays active on client2, although<br>
being older than 1 second and containing an outdated file content. Even if ls<br>
-l already delivers a _new_ file date and _new_ size the file content still<br>
may be outdated (an btw not matching the file size in ls).<br>
You may call that _broken_.<br></blockquote><div><br>Seems like its kernel which is doing caching. Can you apply the attached patch and start glusterfs with option --enable-direct-io-mode and rerun the tests?<br> <br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
> > > Gordan<br>
<br>
> --<br>
> Raghavendra G<br>
<br>
--<br>
Regards,<br>
<font color="#888888">Stephan<br>
</font></blockquote></div><br><br clear="all">regards,<br>-- <br>Raghavendra G<br><br>