关于文件写入的原子性讨论

原创 2017年08月04日 09:19:55

​   文件的写入是否是原子的?多个线程写入同一个文件是否会写错乱?多个进程写入同一个文件是否会写错乱?想必这些问题多多少少会对我们产生一定的困扰,即使知道结果,很多时候也很难将这其中的原理清晰的表达给提问者,侯捷曾说过,源码面前,了无秘密,那么本文也希望从源代码的角度分析上述问题。在开始之前我们需要补充一下Linux 文件相关的一些基础原理,便于更好的看懂Linux源代码。

​   学过Linux的读者想必都应该知道文件的数据分为两个部分,一个部分就是文件数据本身,另外一个部分则是文件的元数据,也就是inode、权限、扩展属性、mtime、ctime、atime等等,inode对于一个文件来说及其的重要,可以唯一的标识一个文件(实际应该是inode + dev号,唯一标识一个文件,更准确来说应该是在同一个文件系统的前提下才成立,不同的文件系统inode是会重复的,不过这不是重点,姑且这里不严谨的认为inode就是用来唯一标识一个文件的吧),内核中将inode号和文件的元数据构建为一个struct inode对象,该对象结构如下:

struct inode {
    umode_t         i_mode;
    uid_t           i_uid;
    gid_t           i_gid;
    unsigned long       i_ino;
    atomic_t        i_count;
    dev_t           i_rdev;
    loff_t          i_size;
    struct timespec     i_atime;
    struct timespec     i_mtime;
    struct timespec     i_ctime;
    .......// 省略
};

​   通过这个inode对象就可以关联一个文件,然后对这个文件进行读写操作,Linux内核对于文件同样也有一个struct file对象来表示,该对象结构如下:

struct file {
    .....
    const struct file_operations    *f_op;
    loff_t          f_pos;
    struct address_space    *f_mapping;
    ....// 省略
};

​   有几个成员比较关键,一个是f_op,文件操作的方法集合,文件操作不用关心其底层的文件系统是什么,直接通过f_op成员找到对应的方法即可。另外一个则是f_pos,也就是这个文件读到哪里了,或者说是写到哪里了,是一个偏移量。一个进程打开一个文件的时候就会在内核中创建一个struct file对象,读取文件的时候则分为以下几步:

  • 通过fd找到对应对应的struct file对象
  • 通过struct file对象获取当前的offset,也就是读取f_pos成员
  • 通过f_op找到对应的操作方法,并传入要读取的偏移量进行数据的读取
  • 读取完成后,重新设置新的offset

一次读文件的过程便是如此,对应到代码也是非常的清晰,如下:

// vfs_read -> do_sync_read
ssize_t do_sync_read(struct file *filp, char __user *buf, size_t len, loff_t *ppos)
{
    struct iovec iov = { .iov_base = buf, .iov_len = len };
    struct kiocb kiocb;
    ssize_t ret;
    // 设置要读取的长度和开始的偏移量
    init_sync_kiocb(&kiocb, filp);
    kiocb.ki_pos = *ppos;
    kiocb.ki_left = len;
    kiocb.ki_nbytes = len;

    for (;;) {
        // 实际开始进行读取操作
        ret = filp->f_op->aio_read(&kiocb, &iov, 1, kiocb.ki_pos);
        if (ret != -EIOCBRETRY)
            break;
        wait_on_retry_sync_kiocb(&kiocb);
    }

    if (-EIOCBQUEUED == ret)
        ret = wait_on_sync_kiocb(&kiocb);
    // 读完后更新最后的offset
    *ppos = kiocb.ki_pos;
    return ret;
}

​   文件的写入也是如此,拿到offet,调用实际的写入方法,最后更新offset。到此为止一个文件的读和写的大体过程我们是清楚了,很显然上述的过程并不是原子的,无论是文件的读还是写,都至少有两个步骤,一个是拿offset,另外一个则是实际的读和写。并且在整个过程中并没有看到加锁的动作,那么第一个问题就得到了解决。对于第二个问题我们可以简要的分析下,假如有两个线程,第一个线程拿到offset是1,然后开始写入,在写入的过程中,第二个线程也去拿offset,因为对于一个文件来说多个线程是共享同一个struct file结构,因此拿到的offset仍然是1,这个时候线程1写结束,更新offset,然后线程2开始写。最后的结果显而易见,线程2覆盖了线程1的数据,通过分析可知,多线程写文件不是原子的,会产生数据覆盖。但是否会产生数据错乱,也就是数据交叉写入了?其实这种情况是不会发生的,至于为什么请看下面这段代码:

ssize_t generic_file_aio_write(struct kiocb *iocb, const struct iovec *iov,
        unsigned long nr_segs, loff_t pos)
{
    struct file *file = iocb->ki_filp;
    struct inode *inode = file->f_mapping->host;
    struct blk_plug plug;
    ssize_t ret;

    BUG_ON(iocb->ki_pos != pos);
    // 文件的写入其实是加锁的
    mutex_lock(&inode->i_mutex);
    blk_start_plug(&plug);
    ret = __generic_file_aio_write(iocb, iov, nr_segs, &iocb->ki_pos);
    mutex_unlock(&inode->i_mutex);

    if (ret > 0 || ret == -EIOCBQUEUED) {
        ssize_t err;

        err = generic_write_sync(file, pos, ret);
        if (err < 0 && ret > 0)
            ret = err;
    }
    blk_finish_plug(&plug);
    return ret;
}
EXPORT_SYMBOL(generic_file_aio_write);

​   所以并不会产生数据错乱,只会存在数据覆盖的问题,既然如此我们在实际的进行文件读写的时候是否需要进行加锁呢? 加锁的确是可以解决问题的,但是在这里未免有点牛刀杀鸡的感觉,好在OS给我们提供了原子写入的方法,第一种就是在打开文件的时候添加O_APPEND标志,通过O_APPEND标志将获取文件的offset和文件写入放在一起用锁进行了保护,使得这两步是原子的,具体代码可以看上面代码中的__generic_file_aio_write函数。


ssize_t __generic_file_aio_write(struct kiocb *iocb, const struct iovec *iov,
                 unsigned long nr_segs, loff_t *ppos)
{
    struct file *file = iocb->ki_filp;
    struct address_space * mapping = file->f_mapping;
    size_t ocount;      /* original count */
    size_t count;       /* after file limit checks */
    struct inode    *inode = mapping->host;
    loff_t      pos;
    ssize_t     written;
    ssize_t     err;

    ocount = 0;
    err = generic_segment_checks(iov, &nr_segs, &ocount, VERIFY_READ);
    if (err)
        return err;

    count = ocount;
    pos = *ppos;

    vfs_check_frozen(inode->i_sb, SB_FREEZE_WRITE);

    /* We can write back this queue in page reclaim */
    current->backing_dev_info = mapping->backing_dev_info;
    written = 0;
    // 重点就在这个函数
    err = generic_write_checks(file, &pos, &count, S_ISBLK(inode->i_mode));
    if (err)
        goto out;
    ......// 省略
}

inline int generic_write_checks(struct file *file, loff_t *pos, size_t *count, int isblk)
{
    struct inode *inode = file->f_mapping->host;
    unsigned long limit = rlimit(RLIMIT_FSIZE);

        if (unlikely(*pos < 0))
                return -EINVAL;

    if (!isblk) {
        /* FIXME: this is for backwards compatibility with 2.4 */
        // 如果带有O_APPEND标志,会直接拿到文件的大小,设置为新的offset
        if (file->f_flags & O_APPEND)
                        *pos = i_size_read(inode);

        if (limit != RLIM_INFINITY) {
            if (*pos >= limit) {
                send_sig(SIGXFSZ, current, 0);
                return -EFBIG;
            }
            if (*count > limit - (typeof(limit))*pos) {
                *count = limit - (typeof(limit))*pos;
            }
        }
    }
    ......// 省略
}

​   通过上面的代码可知,如果带有O_APPEND标志的情况,在文件真正写入之前会调用generic_write_checks进行一些检查,在检查的时候如果发现带有O_APPEND标志就将offset设置为文件的大小。而这整个过程都是在加锁的情况下完成的,所以带有O_APPEND标志的情况下,文件的写入是原子的,多线程写文件是不会导致数据错乱的。另外一种情况就是pwrite系统调用,pwrite系统调用通过让用户指定写入的offset,值得整个写入的过程天然的变成原子的了,在上文说到,整个写入的过程是因为获取offset和文件写入是两个独立的步骤,并没有加锁,通过pwrite省去了获取offset这一步,最终整个文件写入只有一步加锁的文件写入过程了。pwrite的代码如下:

SYSCALL_DEFINE(pwrite64)(unsigned int fd, const char __user *buf,
             size_t count, loff_t pos)
{
    struct file *file;
    ssize_t ret = -EBADF;
    int fput_needed;

    if (pos < 0)
        return -EINVAL;

    file = fget_light(fd, &fput_needed);
    if (file) {
        ret = -ESPIPE;
        if (file->f_mode & FMODE_PWRITE)  
            // 直接把offset也就是pos传递进去,而普通的write需要
            // 需要先从struct file中拿到offset,然后传递进去
            ret = vfs_write(file, buf, count, &pos);
        fput_light(file, fput_needed);
    }

    return ret;
}

SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf,
        size_t, count)
{
    struct file *file;
    ssize_t ret = -EBADF;
    int fput_needed;

    file = fget_light(fd, &fput_needed);
    if (file) {
        // 第一步拿offset
        loff_t pos = file_pos_read(file);
        // 第二步实际的写入
        ret = vfs_write(file, buf, count, &pos);
        // 第三步写回offset
        file_pos_write(file, pos);
        fput_light(file, fput_needed);
    }

    return ret;
}

​   最后一个问题是多个进程写同一个文件是否会造成文件写错乱,直观来说是多进程写文件不是原子的,这是很显而易见的,因为每个进程都拥有一个struct file对象,是独立的,并且都拥有独立的文件offset,所以很显然这会导致上文中说到的数据覆盖的情况,但是否会导致数据错乱呢?,答案是不会,虽然struct file对象是独立的,但是struct inode是共享的(相同的文件无论打开多少次都只有一个struct inode对象),文件的最后写入其实是先要写入到页缓存中,而页缓存和struct inode是一一对应的关系,在实际文件写入之前会加锁,而这个锁就是属于struct inode对象(见上文中的mutex_lock(&inode->i_mutex))的,所有无论有多少个进程或者线程,只要是对同一个文件写数据,拿到的都是同一把锁,是线程安全的,所以也不会出现数据写错乱的情况。

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

通过/proc查看Linux内核态调用栈来定位问题

前几天碰到一个问题:一个进程运行过程中挂死了,把gdb挂上去之后bt打印的内容为空,后来通过查看 /proc 文件系统,查看程的调用栈,才发现是发消息给内核态程序时,内核态一直没有响应,导致用户态进程...

有关fastjson输出的时候double不输出后面.0的问题

最近用fastjson遇到一个很纠结的问题 当用JSON.toJSONString要打印{id:1.0}的时候fastjson会打印{id:1} 后面的.0就这么被他给剪了 追踪源码发现在 ...

linux下多进程写入文件的原子性

【原文链接】 http://tsecer.blog.163.com/blog/static/1501817201311284223689/
  • PlayerL
  • PlayerL
  • 2014年10月07日 11:43
  • 3371

PHP程序的原子性和PHP的文件锁

PHP程序的原子性和PHP的文件锁

文件IO的原子操作

设计多个进程共同操作一个文件的,就需要原子的操作下面几个问题: 1.添加至一个文件 多个进程都要添加数据到一个文件的尾端 if(lseek(fd,0,SEEK_END)>=0) {     ...
  • kinado
  • kinado
  • 2012年08月17日 11:18
  • 1545

由unix文件I/O引出的原子操作

第二遍看APUE,打算把知识点总结一下。问题提出:当两个独立进程A、B同时对一个文件进行追加写操作时(假设这里打开时没有使用O_APPEND参数,即没有从文件尾打开),如果此时进程A调用lseek对该...

3.11 pwrite函数-文件原子写

平write函数用于从打开文件的指定位置处写入指定字节的数据。,函数原型如下: #include ssize_t pwrite(int filedes, const void *buf, size...

[linux]原子化的写文件操作writev

http://linux.die.net/man/2/writev The data transfers performed by readv() and writev() are atomic: t...

UNIX高级环境编程(2)FIle I/O - 原子操作、共享文件描述符和I/O控制函数

UNIX高级环境编程(2)FIle I/O - 原子操作、共享文件描述符和I/O控制函数 引言: 本篇通过对open函数的讨论,引入原子操作,多进程通信(共享文件描述符)和内核相关的数...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:关于文件写入的原子性讨论
举报原因:
原因补充:

(最多只允许输入30个字)