众所周知,glusterFS在客户端有缓存,缓存目的在于提高读性能。那么多个客户端同时对文件进行读写,会不会存在client缓存与server文件不一致的情况?比如client A和client B读写同一文件, client
A修改了server文件,在client B会不会读到旧数据?
第一种说法:读操作时,如果client缓存的timeout未到期,则会读到旧数据。
第二种说法:读操作时,如果发现client缓存与server文件不一致,就会自动同步client缓存。
哪种说法是正确的,本文通过测试给出结论。
实验环境:gluster 3.4 3.5,主机192.168.49.130, 192.168.49.131
创建卷:
gluster volume create vol_512 192.168.49.130:/data/dht 192.168.49.131:/data/dht force #创建一个分布式卷,
卷名为vol_512
设置卷:
gluster volume set vol_512 performance.strict-o-direct on #通过设置允许direct-io来避免内核缓存
gluster volume set vol_512 performance.io-cache on
gluster volume set vol_512performance.cache-refresh-timeout 60
gluster volume set vol_512performance.cache-max-file-size 1MB
启动卷:
gluster volume start vol_512
在192.168.49.130挂载卷mount
-t glusterfs 192.168.49.130:/vol_512 /home/zjj/vol_512
在192.168.49.131挂载卷mount
-t glusterfs 192.168.49.131:/vol_512 /home/zjj/vol_512
192.168.49.130和192.168.49.131同时对文件/home/zjj/vol_512/test进行读写,文件实际存储位置192.168.49.131:/data/dht/test。
我们先在192.168.49.130上不断读文件/home/zjj/vol_512/test,读文件的程序代码:
#include<stdio.h>
#include<stdlib.h>
#include<fcntl.h>
#include<sys/types.h>
#include<unistd.h> int main(void)
{
int fd, len;
char * buf;
fd = open("/home/zjj/vol_512/test", O_RDONLY | O_DIRECT);
while(1){
sleep(1);
len = lseek(fd, 0, SEEK_END);
lseek(fd, 0, SEEK_SET);
buf = (char*)malloc(len);
read(fd, buf, len);
}
close(fd); return 0;
}
我们用nethops工具来监测192.168.49.130 gluster的流量:
如果关闭client cache是什么情况呢?我们来试一下,输入下面命令:
gluster volume set vol_512 performance.io-cache
off
gluster
volume stop vol_512 #重启卷,使配置生效
gluster volume start vol_512#重启卷,使配置生效
关闭client cache后,读文件时流量状况:
通过对比两张流量图,说明192.168.49.130 client cache确实起了作用。
下面,我们重新打开cache,测试192.168.49.131不断写文件的同时(不断产生不一致),192.168.49.130不断读文件的流量是如何变化的。
192.168.49.131 写文件的代码:
#!/bin/bash
while ((1))
do
echo "ads" >> /home/zjj/vol_512/test
done
最开始时,流量情况:
一段时间后,流量状况:
并且流量为直线递增状态,并没有一个timeout周期做一次更新。
所以通过实验证明,每次读不一致文件都会进行client缓存和server文件的同步。