[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