[Gluster-devel] lookup caching

Stephan von Krawczynski skraw at ithnet.com
Fri Apr 2 15:12:01 UTC 2010


On Fri, 02 Apr 2010 15:15:48 +0100
Gordan Bobic <gordan at bobich.net> wrote:

> On 02/04/2010 14:49, Stephan von Krawczynski 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
> 
> That is quite worrying.

I can produce the following effects:

- Edit ascii file on client1, same size, old content on client2
- Edit ascii file on client1 (make it larger, so different size), old content
on client2, but ls -l on client2 shows new file (date and length!)

If you want to try yourself: just edit a file (I did within same minute of
filedate) and look at other clients. Interestingly the servers are always
correct and up to date. It is definitely a caching issue on the client.
I think it corresponds with some self healing issues, because you need a
client for that, too.
I personally think the latest-version detection (if you allow this naming) on
clients is somehow broken.
The clients all contained this config options:

volume replicate
  type cluster/replicate
  option data-self-heal on
  option metadata-self-heal on
  option entry-self-heal on
  subvolumes remote1 remote2
end-volume

volume writebehind
    type performance/write-behind
    option cache-size 4MB
    subvolumes replicate
end-volume

volume readahead
    type performance/read-ahead
    option page-count 4
    subvolumes writebehind
end-volume

volume iocache
    type performance/io-cache
    option cache-size 1GB
    option cache-timeout 1
    subvolumes readahead
end-volume

 
> Gordan

-- 
Regards,
Stephan





More information about the Gluster-devel mailing list