umount异步机制是个什么鬼

场景介绍

  • 远程map一个块设备到机器上,并将这个设备挂在到某个挂载点,作为runcrootfs使用
  • 块设备上的文件系统为xfs
  • 删除runc容器过程中,首先umount 挂载点,然后unmap这个块设备,这两个过程中在代码逻辑上是‘严格’顺序执行

问题描述

umount文件系统的过程中,会大概率导致umount进程D住(处于Uninterruptible状态中),在dmesg看到的直接原因是:设备umap先于文件系统umount操作执行。但是在代码上,两个操作都是同步调用,即直到umount操作正确返回,否则执行流程阻塞,之后才会调用unmap设备,讲道理不应该出现执行顺序异常。

分析过程

第一反应是怀疑umount操作的lazy unmount特性。通过反复研读 man mount以及确认在umount过程中没有其他进程在使用挂载点目录内的文件,基本排除这方便的原因。那究竟是什么导致了这个诡异的行为呢?

我处理问题的思路一般是这样:首先根据已有的知识储备,初步分析可能原因,然后进行google,毕竟如果有人踩过相同的坑,我就别再踩一遍,最后就是在源码中找到本质解,毕竟源码面前无秘密。

下面就根据这个逻辑来进行分析。

可能原因分析

umount操作即然正确返回了,就表示这个过程应该没有异常,但是正确返回,可能并不能保证文件系统就彻底卸载了,莫非umount在内核中是异步的?不然就无法解释。但是扫遍有关umount的参数,都没有提及异步行为。要不先google再说?

google 大法

关键词umount asynchronous,看了两三个小时,还是一无所获,除了发现也有人遇到相同的问题,但是没有看到原因分析和解决方案。看来只能最后一招了:源码中寻找答案。

kernel 代码走读

重点走读umount的流程,功夫不负有心人,终于在fs/namespace.c中看到如下代码片段

    if (likely(!(mnt->mnt.mnt_flags & MNT_INTERNAL))) {
            struct task_struct *task = current;
            if (likely(!(task->flags & PF_KTHREAD))) {
                    init_task_work(&mnt->mnt_rcu, __cleanup_mnt);
                    if (!task_work_add(task, &mnt->mnt_rcu, true))
                            return;
            }
            if (llist_add(&mnt->mnt_llist, &delayed_mntput_list))
                    schedule_delayed_work(&delayed_mntput_work, 1);
            return;
    }
    cleanup_mnt(mnt);

不用深究每行代码表示什么意思,根据名称就可以知道这段代码大概是在做什么。其实就是判断mount的参数中是否有MNT_INTERNAL,若没有,则将__cleanup_mnt放到一个task queue中,函数返回;反之则直接进入cleanup_mnt.这下真相大白:umount操作在新版内核中确实默认是异步操作,它正确从内核返回到用户空间,并不表示文件系统已经完全umount

解决之道

原因清楚了,机制明白了,问题就迎刃而解了:在mount过程中增加一个参数MS_KERNMOUNT。不过貌似man mount中并不能找到这个参数,但是mount系统调用函数中能找到这个参数。至于MS_KERNMOUNTMNT_INTERNAL是什么关系,就留给各位自己思考吧~

整个过程到这里应该算结束了,但为了搞清楚为什么kernel要这么处理。我在github上找了上面这段代码的修改历史。在v3.18-rc1中,这个异步机制被加到kernel 主线: https://github.com/torvalds/linux/commit/9ea459e110df32e60a762f311f7939eaa879601d . 至于为什么会加入这个特性,可以参考https://lwn.net/Articles/494158/。

你可能感兴趣的:(umount异步机制是个什么鬼)