On Sat, Apr 3, 2010 at 6:22 PM, Stephan von Krawczynski <skraw@xxxxxxxxxx> wrote:
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?
To make this point clear:On Sat, 3 Apr 2010 17:02:38 +0400
Raghavendra G <raghavendra@xxxxxxxxxxx> wrote:
> On Fri, Apr 2, 2010 at 5:49 PM, Stephan von Krawczynski <skraw@xxxxxxxxxx>wrote:
>
> > On Fri, 02 Apr 2010 14:41:36 +0100
> > Gordan Bobic <gordan@xxxxxxxxxx> 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.
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
Attachment:
0001-fuse-change-behavior-of-direct-io-mode.patch
Description: Binary data
