[Gluster-devel] lookup caching

[Raghavendra G]

On Sat, Apr 3, 2010 at 6:22 PM, Stephan von Krawczynski <skraw at ithnet.com>wrote:

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

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?


>
> > > > Gordan
>
> > --
> > Raghavendra G
>
> --
> Regards,
> Stephan
>


regards,
-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20100405/5fba6f8d/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fuse-change-behavior-of-direct-io-mode.patch
Type: application/octet-stream
Size: 6209 bytes
Desc: not available
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20100405/5fba6f8d/attachment-0003.obj>