MyException - 我的异常网
当前位置:我的异常网» 行业应用 » 关于文件写下的原子性讨论

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

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

​   文件的写入是否是原子的?多个线程写入同一个文件是否会写错乱?多个进程写入同一个文件是否会写错乱?想必这些问题多多少少会对我们产生一定的困扰,即使知道结果,很多时候也很难将这其中的原理清晰的表达给提问者,侯捷曾说过,**源码面前,了无秘密**,那么本文也希望从源代码的角度分析上述问题。在开始之前我们需要补充一下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))的,所有无论有多少个进程或者线程,只要是对同一个文件写数据,拿到的都是同一把锁,是线程安全的,所以也不会出现数据写错乱的情况。

版权声明:本文内容由互联网用户自发贡献,本社区不拥有所有权,也不承担相关法律责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:yqgroup@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

文章评论

程序员最害怕的5件事 你中招了吗?
程序员最害怕的5件事 你中招了吗?
那些性感的让人尖叫的程序员
那些性感的让人尖叫的程序员
十大编程算法助程序员走上高手之路
十大编程算法助程序员走上高手之路
10个帮程序员减压放松的网站
10个帮程序员减压放松的网站
老程序员的下场
老程序员的下场
 程序员的样子
程序员的样子
初级 vs 高级开发者 哪个性价比更高?
初级 vs 高级开发者 哪个性价比更高?
一个程序员的时间管理
一个程序员的时间管理
旅行,写作,编程
旅行,写作,编程
如何区分一个程序员是“老手“还是“新手“?
如何区分一个程序员是“老手“还是“新手“?
2013年美国开发者薪资调查报告
2013年美国开发者薪资调查报告
Java 与 .NET 的平台发展之争
Java 与 .NET 的平台发展之争
“懒”出效率是程序员的美德
“懒”出效率是程序员的美德
程序员都该阅读的书
程序员都该阅读的书
程序员应该关注的一些事儿
程序员应该关注的一些事儿
Java程序员必看电影
Java程序员必看电影
我是如何打败拖延症的
我是如何打败拖延症的
当下全球最炙手可热的八位少年创业者
当下全球最炙手可热的八位少年创业者
程序员的鄙视链
程序员的鄙视链
团队中“技术大拿”并非越多越好
团队中“技术大拿”并非越多越好
鲜为人知的编程真相
鲜为人知的编程真相
程序员的一天:一寸光阴一寸金
程序员的一天:一寸光阴一寸金
Web开发者需具备的8个好习惯
Web开发者需具备的8个好习惯
程序员周末都喜欢做什么?
程序员周末都喜欢做什么?
什么才是优秀的用户界面设计
什么才是优秀的用户界面设计
我跳槽是因为他们的显示器更大
我跳槽是因为他们的显示器更大
为啥Android手机总会越用越慢?
为啥Android手机总会越用越慢?
每天工作4小时的程序员
每天工作4小时的程序员
要嫁就嫁程序猿—钱多话少死的早
要嫁就嫁程序猿—钱多话少死的早
2013年中国软件开发者薪资调查报告
2013年中国软件开发者薪资调查报告
不懂技术不要对懂技术的人说这很容易实现
不懂技术不要对懂技术的人说这很容易实现
10个调试和排错的小建议
10个调试和排错的小建议
写给自己也写给你 自己到底该何去何从
写给自己也写给你 自己到底该何去何从
为什么程序员都是夜猫子
为什么程序员都是夜猫子
Google伦敦新总部 犹如星级庄园
Google伦敦新总部 犹如星级庄园
我的丈夫是个程序员
我的丈夫是个程序员
程序猿的崛起——Growth Hacker
程序猿的崛起——Growth Hacker
代码女神横空出世
代码女神横空出世
漫画:程序员的工作
漫画:程序员的工作
亲爱的项目经理,我恨你
亲爱的项目经理,我恨你
总结2014中国互联网十大段子
总结2014中国互联网十大段子
程序员必看的十大电影
程序员必看的十大电影
程序员和编码员之间的区别
程序员和编码员之间的区别
聊聊HTTPS和SSL/TLS协议
聊聊HTTPS和SSL/TLS协议
看13位CEO、创始人和高管如何提高工作效率
看13位CEO、创始人和高管如何提高工作效率
如何成为一名黑客
如何成为一名黑客
老美怎么看待阿里赴美上市
老美怎么看待阿里赴美上市
“肮脏的”IT工作排行榜
“肮脏的”IT工作排行榜
中美印日四国程序员比较
中美印日四国程序员比较
软件开发程序错误异常ExceptionCopyright © 2009-2015 MyException 版权所有