拷贝文件到GlusterFS卡住的解决过程

111

　　问题简介
我们有一个分布式服务，存储为Gluster FS，需要大量的读写文件。在公司开发环境、测试环境都正常的情况下，在线上环境、高仿环境却屡屡出现拷贝文件到Gluster FS卡住的问题（文件若是200M~5G大小，概率大概在3~4%左右，文件已拷贝完成，源文件和目标文件md5一致，卡在目标文件句柄close处。）。
相关issue:https://github.com/gluster/glusterfs/issues/341
　　func CopyFile(src, dest string) (copiedSize int64, err error) {
copiedSize = 0
srcFile, err := os.Open(src)
if err != nil {
return copiedSize, err
}
defer srcFile.Close()

destFile, err := os.Create(dest)
if err != nil {
return copiedSize, err
}
defer destFile.Close() // 卡在这
return io.Copy(destFile, srcFile)
　　}
卡住的goroutine信息示例：
　　goroutine 109667 [syscall, 711 minutes]:
syscall.Syscall(0x3, 0xf, 0x0, 0x0, 0xafb1a0, 0xc42000c150, 0x0)
/usr/local/go/src/syscall/asm_linux_amd64.s:18 +0x5
syscall.Close(0xf, 0x0, 0x0)
/usr/local/go/src/syscall/zsyscall_linux_amd64.go:296 +0x4a
os.(file).close(0xc420344f00, 0x455550, 0xc4203696d0)
/usr/local/go/src/os/file_unix.go:140 +0x86
os.(File).Close(0xc4200289f0, 0x1b6, 0xc4200289f0)
/usr/local/go/src/os/file_unix.go:132 +0x33
Common/utils.CopyFile(0xc42031eea0, 0x5d, 0xc420314840, 0x36, 0x10ce9d94, 0x0, 0x0)
......
最后的/usr/local/go/src/syscall/asm_linux_amd64.s第18行前后代码如下
　　TEXT    ·Syscall(SB),NOSPLIT,$0-56
CALL    runtime·entersyscall(SB)   // 卡在系统调用开始处
MOVQ    a1+8(FP), DI
MOVQ    a2+16(FP), SI
MOVQ    a3+24(FP), DX
MOVQ    $0, R10
MOVQ    $0, R8
MOVQ    $0, R9
MOVQ    trap+0(FP), AX  // syscall entry
SYSCALL
CMPQ    AX, $0xfffffffffffff001
JLS ok
MOVQ    $-1, r1+32(FP)
MOVQ    $0, r2+40(FP)
NEGQ    AX
MOVQ    AX, err+48(FP)
CALL    runtime·exitsyscall(SB)
RET
ok:
MOVQ    AX, r1+32(FP)
MOVQ    DX, r2+40(FP)
MOVQ    $0, err+48(FP)
CALL    runtime·exitsyscall(SB)
RET
解决过程
由于开发环境、测试环境用的Gluster FS是3.3.2，线上环境、高仿环境的Gluster FS版本是3.7.6，最开始是猜测可能是版本不一致导致的问题。因此最开始是从Gluster FS版本是否有问题，部署GlusterFS的软硬件是否有问题开始入手，
但始终找不出真正的原因。这时候公司流程就成了阻碍，因为原因基本靠经验猜测，但即便改一点点代码，都要提测，找多个领导签字，最坏的一次情况是一天都没走完一个流程。
最后，实在无奈，向领导申请操作部分高仿环境的权限。好了，终于可以施展拳脚了。
　　第一次，采用超时处理机制
我们想到的是，参考tensorflow的源码，在Golang中用reflect实现一个类似 ./tensorflow/core/platform/cloud/retrying_utils.cc的代码。基本原理就是，close等一些可能会卡住的函数是新启一个goroutine来做，如果在close阶段卡住，超过一定时间继续往下走，反正文件都已经拷贝完了。
主要代码如下：
　　type RetryingUtils struct {
Timeout    time.Duration
MaxRetries int
}
　　type CallReturn struct {
Error        error
ReturnValues []reflect.Value
}
　　func NewRetryingUtils(timeout time.Duration, maxRetries int) *RetryingUtils {
return &RetryingUtils{Timeout: timeout, MaxRetries: maxRetries}
}
　　func (r *RetryingUtils) CallWithRetries(any interface{}, args ...interface{}) CallReturn {
var callReturn CallReturn
var retries int
for {
callReturn.Error = nil
done := make(chan int, 1)
go func() {
function := reflect.ValueOf(any)
inputs := make([]reflect.Value, len(args))
for i, _ := range args {
inputs = reflect.ValueOf(args)
}
callReturn.ReturnValues = function.Call(inputs)
done  volume info
　　Volume Name: pre-volume
Type: Striped-Replicate
Volume ID: 3b018268-6b4b-4659-a5b0-38e1f949f10f
Status: Started
Number of Bricks: 1 x 2 x 2 = 4
Transport-type: tcp
Bricks:
Brick1: 10.10.20.201:/data/pre
Brick2: 10.10.20.202:/data/pre
Brick3: 10.10.20.203:/data/pre
Brick4: 10.10.20.204:/data/pre
Options Reconfigured:
performance.flush-behind: OFF // 此处若为on，就Ok
diagnostics.count-fop-hits: on
diagnostics.latency-measurement: on
performance.readdir-ahead: on