文件的多进程读写

一直以为多进程读写文件是安全的,只有fflush和fclose才会真正修改文件内容,诸多开源项目的日志系统也基本都是多线程的,asterisk同样没有为ast_log建立一个专门的日志线程,而是各自调用,通过fflush直接写缓存。但是最近在8032上面发现的一个问题改变了我的看法。

问题描述:
跟踪用户设备时发现网管配置文件snmp.conf出现过几次文件内容丢失的情况,实验室环境也同样出现过,多出现在恢复配置,重启时,难以重现,没有规律。

重现模型:
在实际使用中较难重现,因此考虑通过实验来放大问题,找出原因。
1. 编写test可执行程序,功能是修改test.txt中的一个字段,并保存。
2. 编写test.sh脚本,无限循环执行test程序。
3. 分别开两个命令行窗口,执行test.sh,模拟文件的多进程读写模型。

拷机半分钟到一分钟后,就会出现test.txt文件内容被清空的情况,问题重现。

问题分析:
文件内容的修改,常用算法是先r只读模式读出文件内容,在字符串中修改文件内容,然后再通过w写模式打开文件,写入修改后的字符串,保存退出。如下图模型。

文件的多进程读写_第1张图片

虽然做了实验重现了现象,还是觉得难以理解,fclose是如此的安全,甚至让我觉得对它有任何的怀疑都是一种亵渎。于是在如图A,B,C,D,E处分别做了sleep延时处理,然后另一进程进行文件修改操作。
实验后发现,问题出在D处。fclose的确是安全的,但是w模式不是。w模式打开文件后,文件长度被立即截断为0,而不是在fclose后才修改,此时另一进程读此文件就会发生读到空数据的问题。

进一步分析:
w模式是不安全的,那么同样常用的a模式呢。APUE 5.5 打开流 中提到

当用添加类型打开一文件后,则每次写都将数据写到文件的当前尾端处。如若有多个进程用标准I / O添加方式打开了同一文件,那么来自每个进程的数据都将正确地写到文件中。

那么Linux是如何保证a模式的多进程安全性呢。APUE 中提到

3.10 文件共享

如果用O_APPEND标志打开了一个文件,则相应标志也被设置到文件表项的文件状态标志中。每次对这种具有添写标志的文件执行写操作时,在文件表项中的当前文件位移量首先被设置为i节点表项中的文件长度。这就使得每次写的数据都添加到文件的当前尾端处。

3.11 原子操作
UNIX提供了一种方法是这种操作(文件写入)成为原子操做, 其方法就是在打开文件时设置O_APPEND标志。

上述内容让人对a模式的安全性有了一点信心,但是注意到文件写入最终是通过系统调用write实现的,系统调用本身是可能发生CPU进程调度的,那么Linux如何保证一次文件写入过程中不会被另一个写入进程插入呢。比如一个进程写入10个a,另一个进程写入10个b,如何保证这10个a和10个b之间不会互相交错呢。

APUE上没有找到对write原子性的明确描述,但是在 15.2 管道 中提到

在写管道时,常数PIPE_BUF规定了内核中管道缓存器的大小。如果对管道进行write调用,而且要求写的字节数小于等于PIPE_BUF,则此操作不会与其他进程对同一管道(或FIFO)的write操作穿插进行。但是,若有多个进程同时写一个管道(或FIFO),而且某个或某些进程要求写的字节数超过PIPE_BUF字节数,则数据可能会与其他写操作的数据相穿插。

可见,write的原子性其实还是有限制的,管道有PIPE_BUF的限制(PIPE_BUF值一般为512),可以想见,普通文件应该也是有一个限制值,很难想象如果write个几G的数据都是原子操作的话系统会变成一个什么模样,因此,可以认为,在write较少的数据时,linux内核保证了它的原子性,但是一次写入数据较多时,write是可能被其他操作中途插入的。

结论:
文件的多进程读写并不是绝对安全的,因此,如果要保证一个文件的绝对安全,应该保证同一时刻仅有一个进程在打开它修改它,比较好的方法应该是syslog的做法,建立一个监听线程专门负责该文件写入,其他线程通过向该线程发送消息队列来写入数据,次一些的方法可以使用文件锁等。

对于不是非常关心文件安全的模块来说(如log模块),则应该采用a模式的方法写入数据。

对于不适用于a模式的模块来说(如配置文件,需要修改配置文件,而不是从尾部添加),则应尽量避免多进程读写同一文件,从这点意义上说,asterisk的ast_config模块同样存在该问题,一旦发生多进程读写,就有文件内容丢失的风险。

注意到文件丢失实际上是由w模式引起的,那么如果非要多进程修改文件,又不愿意专门新建线程写文件的话,可以通过以下方法折中处理规避文件内容丢失问题。

1. r+读写模式打开文件。
2. 读出文件内容到内存中。
3. 修改内存中内容。
4. 重定向到文件头部。
5. 写入修改后的文件内容。
6. 关闭文件。
7. 截断文件。

采用r+的文件打开方式,规避了w模式的弊端,另外结合截断函数实现对文件尾部的正确修改,截断函数原型如下:

NAME
truncate, ftruncate - truncate a file to a specified length

SYNOPSIS
#include
#include

int truncate(const char *path, off_t length);
int ftruncate(int fd, off_t length);

通过该方法修改上述模型,多进程执行test.sh后文件内容没有丢失。但是注意到,关闭文件和截断文件毕竟是两个函数,不是原子操作,因此中间是可能被其他操作中断或插入,但可以肯定的是,不会出现文件内容丢失的情况。

你可能感兴趣的:(Linux,其他)