小时候站在田间地头看着旁边的公路无限延伸，总在想它会通向什么地方，长大后走的越来越远，又开始回望故乡的方向。

有没有知乎的，我想关掉广告

jingle bell. not jing bell

康复新液（蟑螂汁）也很好用

在 qemu 里跑

这是哆啦 A 梦的口袋

空窗期真是个蛋疼的事情

@orange 进局子

《编译器设计》

防君子不防小人，拿其他手机拍一个

这站点怎么盈利，打广告吗...

@julyclyde 你真的是.....那我来给你讲讲代码吧...

首先，你讲的/proc/pid/mounts 是 pid 这个进程所在的命名空间里挂载的所有文件系统列表，跟题主的问题没有任何关系，题主没有涉及 namespace 的切换，主进程和 sdk （子进程之类的）处于同一个 namespace 。

其次，让我们看一下 vfs 层的代码，

path_lookupat 函数负责解析路径分量，path_init 负责初始化路径分量的解析起点，对于 ls . 这个命令来讲，我们把起点设定为 fs->pwd ，也就是/proc/pid/cwd 的值。放在题主的环境里起点就是 workdir 这个父目录
然后函数进入 link_path_walk 开始正式解析路径分量，由于我们的入参 name="."，所以此函数一个循环直接结束，不会进一步进入 walk_component 函数了。link_path_walk 返回 0 ，此时入参 nd 直接把父目录 workdir 带回了。上层函数 path_lookupat 直接调用 lookup_last 把父目录相关的 dentry 和 inode 准备好，然后层层返回，路径查找结束。

那么再来看看 ls /tmp/workdir 的情况，路径分量解析起点是/，即父文件系统的根目录。然后 name="/tmp/workdir"被 link_path_walk 逐段解析，由于/后是 tmp 字符串，所以调用 walk_component 首先解析 tmp ，这个环节无事发生，再然后使用 walk_component 继续进入 workdir 这个子目录，此时发现 workdir 的 dentry 上有个标志位 DCACHE_MOUNTED(mount 系统调用是给 workdir 这个挂载点设置的，参见函数 d_set_mounted)，这说明了什么？说明这是个挂载点，于是 lookup_mnt 被调用，路径查找流程开始“下降”到子文件系统，所以我们要解析的下一个分量不再是父文件系统的 workdir 目录，而是子文件系统的根目录。于是我们就看到了新的内容。


对比以上两个过程，我们会发现当 ls . 的时候，由于. 是个特殊的分量，内核会特殊的处理，所以不会走 walk_component ，也就没机会检测到当前目录上的 DCACHE_MOUNTED 标志。
而我们 ls 一个/tmp/workdir 的时候，迫使内核重新走一遍路径分量解析，它就能发现 DCACHE_MOUNTED 标志。

这就是为什么 ls . 永远看到旧内容，而 ls ../workdir 或者 ls /tmp/workdir 却可以看到新内容

当然是《 redis 设计与实现》

@julyclyde `ls . `这个命令不会做路径查找，而是直接获取进程 cwd ，所以看到的是老内容，但是 ls /tmp/workdir 需要解析路径，在 open 系统调用时会做 walk path ，路径分量解析到 workdir 这一层发现 dentry 设置了挂载标志，表示这是个挂载点，于是路径查找下降到子文件系统，就看到了新内容。

为今之计建议再建立一层目录，形成/tmp/common/workdir 的结构，主进程和 sdk 都切换到 common 这一层，然后主进程在 workdir 挂载文件系统，sdk 每次读取时去子目录 workdir 下找文件。这样不管 workdir 怎么被遮盖，sdk 每次都要做目录查找，看到的一定是最新的