datasheet

Linux阅码场

文章数:353 被阅读:346698

账号入驻

张义飞: 关于文件写入的原子性讨论

2018-10-25
    阅读数:

        文件的写入是否是原子的?多个线程写入同一个文件是否会写错乱?多个进程写入同一个文件是否会写错乱?想必这些问题多多少少会对我们产生一定的困扰,即使知道结果,很多时候也很难将这其中的原理清晰的表达给提问者,侯捷曾说过,源码面前,了无秘密,那么本文也希望从源代码的角度分析上述问题。在开始之前我们需要补充一下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对象来表示,该对象结构如下:    

// 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))的,所有无论有多少个进程或者线程,只要是对同一个文件写数据,拿到的都是同一把锁,是线程安全的,所以也不会出现数据写错乱的情况。

本文来源:Linux内核之旅



查看"Linux阅码场"精华技术文章请移步:

Linux阅码场精华文章汇总


扫描二维码关注"Linux阅码场" 

About Us 关于我们 客户服务 联系方式 器件索引 网站地图 最新更新 手机版

站点相关: TI培训

北京市海淀区知春路23号集成电路设计园量子银座1305 电话:(010)82350740 邮编:100191

电子工程世界版权所有 京ICP证060456号 京ICP备10001474号 电信业务审批[2006]字第258号函 京公海网安备110108001534 Copyright © 2005-2018 EEWORLD.com.cn, Inc. All rights reserved