# 一台普通机器上同时挂载着多少种"文件系统"
findmnt -o TARGET,FSTYPE | awk 'NR>1{print $2}' | sort -u
# autofs   bpf      cgroup2  configfs  debugfs  devpts   devtmpfs
# efivarfs ext4     fusectl  hugetlbfs mqueue  overlay  proc
# pstore   securityfs sysfs   tmpfs    tracefs  xfs

cat /proc/filesystems | wc -l          # 内核支持的类型数

// 应用代码、甚至内核里的大部分代码，都只用这一组接口
int fd = open(path, flags);
read(fd, buf, n);
write(fd, buf, n);
close(fd);

// include/linux/fs.h（简化）
struct file_operations {
    struct module *owner;
    loff_t (*llseek)(struct file *, loff_t, int);
    ssize_t (*read_iter)(struct kiocb *, struct iov_iter *);
    ssize_t (*write_iter)(struct kiocb *, struct iov_iter *);
    int (*open)(struct inode *, struct file *);
    int (*release)(struct inode *, struct file *);       // 对应 close
    int (*fsync)(struct file *, loff_t, loff_t, int datasync);
    long (*unlocked_ioctl)(struct file *, unsigned int, unsigned long);
    int (*mmap)(struct file *, struct vm_area_struct *);
    __poll_t (*poll)(struct file *, struct poll_table_struct *);   // epoll 用它
    ssize_t (*splice_read)(...);                                    // 零拷贝
    ...
};

// ext4 的实现（fs/ext4/file.c）
const struct file_operations ext4_file_operations = {
    .llseek         = ext4_llseek,
    .read_iter      = ext4_file_read_iter,
    .write_iter     = ext4_file_write_iter,
    .unlocked_ioctl = ext4_ioctl,
    .mmap           = ext4_file_mmap,
    .fsync          = ext4_sync_file,
    ...
};

// 管道的实现（fs/pipe.c）—— 同一组接口，完全不同的语义
const struct file_operations pipefifo_fops = {
    .llseek     = no_llseek,          // ✅ 管道不支持 seek —— 直接返回错误
    .read_iter  = pipe_read,
    .write_iter = pipe_write,
    .poll       = pipe_poll,
    ...
};

// socket 的实现（net/socket.c）
static const struct file_operations socket_file_ops = {
    .llseek     = no_llseek,
    .read_iter  = sock_read_iter,
    .write_iter = sock_write_iter,
    .poll       = sock_poll,
    ...
};

// fs/read_write.c（大幅简化）
ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
{
    if (!(file->f_mode & FMODE_READ))  return -EBADF;
    if (!file->f_op->read_iter)        return -EINVAL;
    return call_read_iter(file, &kiocb, &iter);   // ← 通过函数指针分派到具体实现
    //     ^^^^^^^^^^^^^^ 本质上是 file->f_op->read_iter(...)
}

// unlink 是【父目录 inode】的操作，不是文件自己的操作
// fs/namei.c
int vfs_unlink(struct inode *dir, struct dentry *dentry, ...)
//             ^^^^^^^^^^^^^^^^ 传进来的是【父目录】的 inode
{
    error = may_delete(dir, dentry, false);   // ← 检查【父目录】的写权限
    ...
    error = dir->i_op->unlink(dir, dentry);   // ← 调用父目录 inode 的 unlink
}

# 两次 open 各有独立的读写偏移量
exec 3< /etc/passwd
exec 4< /etc/passwd
head -c 10 <&3 >/dev/null     # fd 3 的偏移量前进 10
# fd 4 的偏移量还是 0 —— 两个 struct file 各自独立

ls -l /proc/$$/fd/3 /proc/$$/fd/4     # 指向同一个文件
cat /proc/$$/fdinfo/3                  # ✅ 能直接看到偏移量
# pos:    10
# flags:  02000000
cat /proc/$$/fdinfo/4
# pos:    0                            <- 独立的偏移量
exec 3<&- 4<&-

cd /tmp && echo data > a.txt && ln a.txt b.txt
stat -c '%i %h' a.txt b.txt
# 2621441 2
# 2621441 2                            <- 同一个 inode，两个名字（04 篇 1.1）

# 这是很多人不知道的行为
cat > /tmp/fork_test.sh <<'EOF'
exec 3> /tmp/out.txt
( echo "child-line" >&3 ) &        # 子进程（fork 出来的）写
wait
echo "parent-line" >&3             # 父进程写
exec 3>&-
EOF
bash /tmp/fork_test.sh && cat /tmp/out.txt
# child-line
# parent-line                      <- ✅ 没有互相覆盖！

# ✅ 多个子进程写同一个重定向目标不会互相覆盖（共享偏移量）
{ echo a; echo b; } > /tmp/f          # 两个 echo 是同一个 shell 的
( echo x; echo y ) > /tmp/f2          # 子 shell 里的多条命令
for i in 1 2 3; do echo $i & done > /tmp/f3; wait   # 并发写，各自追加不覆盖
cat /tmp/f3      # 三行都在（顺序可能乱，但不丢）

# ❌ 但每次重新打开就不共享了
echo a > /tmp/f4
echo b > /tmp/f4                       # 第二次 open 带 O_TRUNC，截断了文件
cat /tmp/f4      # 只有 b

int fd1 = open("f", O_WRONLY);
int fd2 = dup(fd1);                    // ✅ 两个 fd，【同一个 struct file】→ 共享偏移量
int fd3 = open("f", O_WRONLY);         // 两个 struct file → 偏移量独立

// 这就是 09 篇 2.2 讲的 2>&1 的本质：
//   dup2(1, 2) 让 fd 2 指向 fd 1【当时指向的那个 struct file】
//   所以之后 fd 1 改指向别处，fd 2 不受影响

// include/linux/fs.h（简化并注释）
struct file {
    struct path         f_path;       // 包含 dentry 和 vfsmount（见第 5 章）
    struct inode        *f_inode;     // 缓存的 inode 指针（快速访问）
    const struct file_operations *f_op;   // ← 操作表：决定 read/write 的实际行为
    atomic_long_t       f_count;      // 引用计数（dup/fork 会增加）
    unsigned int        f_flags;      // O_RDONLY / O_APPEND / O_NONBLOCK …
    fmode_t             f_mode;       // FMODE_READ / FMODE_WRITE
    loff_t              f_pos;        // ✅ 当前读写偏移量（每个 open 独立）
    struct fown_struct  f_owner;      // 异步 I/O 的信号接收者
    void                *private_data;// 具体实现的私有数据（如 socket、epoll 实例）
    struct address_space *f_mapping;  // page cache（指向 inode 的 i_mapping）
    ...
};

# 从用户态观察这些字段
PID=$$
cat /proc/$PID/fdinfo/1
# pos:    0                          <- f_pos
# flags:  02100002                   <- f_flags（八进制）
# mnt_id: 26                         <- 属于哪个挂载点（vfsmount）
# ino:    6                          <- inode 号

# epoll 实例的 fdinfo 更有信息量（31 篇会用到）
# tfd:    5  events: 19  data: ...   <- 它监视的每个 fd

// fd 只是一个数组下标（04 篇 1.1 说过）
struct task_struct {              // 进程描述符
    struct files_struct *files;   // 打开文件表
    ...
};
struct files_struct {
    atomic_t count;               // ✅ 引用计数：线程共享同一份（vfork/clone 时）
    struct fdtable __rcu *fdt;
    ...
};
struct fdtable {
    unsigned int max_fds;
    struct file __rcu **fd;       // ✅ 就是一个数组：fd[3] 就是 fd 3 对应的 struct file
    unsigned long *close_on_exec; // FD_CLOEXEC 位图
    unsigned long *open_fds;      // 哪些 fd 已被占用
    ...
};

# ① 为什么 fd 号总是「最小可用的整数」
#    因为内核在 open_fds 位图里找第一个空位
exec 3<&- ; exec 5< /etc/hosts     # 关掉 3，再开一个会拿到 3 而不是 6
ls /proc/$$/fd

# ② 为什么 ulimit -n 限制的是「每进程」的 fd 数（13 篇 8.1）
#    因为 fdtable 是 per-process 的
cat /proc/self/limits | grep 'open files'

# ③ 为什么线程之间共享 fd
#    clone(CLONE_FILES) 让新线程复用同一个 files_struct
#    → 一个线程 open 的 fd，另一个线程能直接用

# ④ FD_CLOEXEC 是怎么实现的
#    execve() 时内核遍历 close_on_exec 位图，关掉标记过的 fd
#    这就是为什么现代 API 都提供 O_CLOEXEC（避免 fd 泄漏给子进程）

// Go 里所有 fd 默认带 O_CLOEXEC，这是有意的设计
// 否则 exec.Command 起的子进程会继承一堆无关 fd（安全风险 + fd 泄漏）
f, _ := os.Open("x")     // 内部用 openat(..., O_CLOEXEC)
// 需要故意传给子进程时，要用 cmd.ExtraFiles
cmd := exec.Command("child")
cmd.ExtraFiles = []*os.File{f}    // 会成为子进程的 fd 3

# ① strace 看系统调用层
strace -e trace=read,openat cat /etc/hostname
# openat(AT_FDCWD, "/etc/hostname", O_RDONLY) = 3
# read(3, "myhost\n", 131072) = 7
# read(3, "", 131072) = 0                    <- 返回 0 = EOF

# ② ftrace 看内核函数调用链（需要 root）
sudo trace-cmd record -p function_graph -g vfs_read -- cat /etc/hostname
sudo trace-cmd report | head -40
# 能看到 vfs_read -> ext4_file_read_iter -> generic_file_read_iter -> filemap_read

# ③ bpftrace 统计各文件系统的 read 分布
sudo bpftrace -e 'kprobe:vfs_read { @[comm] = count(); }'
sudo bpftrace -e 'kprobe:ext4_file_read_iter { @bytes = hist(arg2); }'

# ④ 看是否命中 page cache（未命中才会真的读磁盘）
sudo bpftrace -e '
  kprobe:filemap_read { @total = count(); }
  kprobe:submit_bio   { @disk_io = count(); }
'
# @total 远大于 @disk_io 说明 page cache 命中率高

# ⑤ 看整条路径的耗时分布
sudo bpftrace -e 'kprobe:vfs_read { @start[tid] = nsecs; }
  kretprobe:vfs_read /@start[tid]/ { @us = hist((nsecs - @start[tid])/1000); delete(@start[tid]); }'

# ① 为什么 page cache 命中时 read 极快（05 篇的缓冲、11 篇的 df/du）
#    命中时在第 ④ 步就返回了，根本不碰磁盘

# ② 为什么进程会卡在 D 状态（13 篇 2.5）
#    第 ⑨ 步等硬件完成时进程睡在不可中断状态

# ③ 为什么 O_DIRECT 能绕过 page cache
#    它跳过 ④⑤，直接走 ⑦（代价是失去缓存与预读）

# ④ 为什么 sendfile/splice 能零拷贝（32 篇细讲）
#    它们在内核内部把 page cache 的页直接交给 socket，省掉「拷到用户态再拷回来」

# 看 dcache 的规模
grep -E 'dentry|inode_cache' /proc/slabinfo | awk '{print $1, $2, $3}'
# dentry            1234567  1234567       <- 活跃对象数 / 总对象数
# ext4_inode_cache   456789   456789
sudo slabtop -o | head -8                  # 更直观

# dcache 属于「可回收的内核内存」，算在 SReclaimable 里
grep -E 'SReclaimable|SUnreclaim' /proc/meminfo

# 手动回收（⚠️ 生产上慎用，会导致后续路径解析全部 miss）
sync; echo 2 | sudo tee /proc/sys/vm/drop_caches    # 2 = 只清 dentry 和 inode 缓存

// 负 dentry（negative dentry）：d_inode == NULL 的 dentry
// 它表示「这个名字确定不存在」，避免重复查磁盘

# 为什么需要它？因为「查找失败」也很频繁
strace -f -e trace=openat python3 -c 'import json' 2>&1 | grep -c ENOENT
# 几十到上百次 ENOENT —— 解释器在多个目录里搜索模块，大部分是失败的
# 同类场景：动态链接器搜索 .so、shell 搜索 PATH（01 篇 3.1）、
#          Java 找 class、编译器找头文件

# 没有负 dentry 的话，每次失败的查找都要读一次磁盘目录

# 观察负 dentry 数量（需要 root）
sudo bpftrace -e 'kprobe:d_alloc { @ = count(); }' 2>/dev/null
# 或者从 slabinfo 看 dentry 总数持续增长但文件数没变

# 内核会在内存压力下回收它们，但如果 dentry 占用异常大：
echo 2 | sudo tee /proc/sys/vm/drop_caches
sysctl vm.vfs_cache_pressure          # 默认 100，调大会让内核更激进地回收 dcache

# 观察两条路径的比例
sudo bpftrace -e '
  kprobe:path_lookupat { @lookup = count(); }
  kprobe:unlazy_walk   { @fallback_to_refwalk = count(); }
'
# @fallback 占比高说明有大量软链接或跨挂载点访问

// 软链接在 VFS 里的处理：inode_operations 里有 get_link()
struct inode_operations {
    const char *(*get_link)(struct dentry *, struct inode *, struct delayed_call *);
    ...
};
// 路径解析遇到软链接时：
//   ① 调 get_link() 拿到目标路径字符串
//   ② 【递归】解析这个新路径
//   ③ 用 nd->depth 计数，超过 MAXSYMLINKS（40）就返回 ELOOP

# 验证 40 层限制（03 篇 6.3 提过）
cd /tmp && ln -s a b && ln -s b a
cat a
# cat: a: Too many levels of symbolic links       <- ELOOP

# 内核里这个限制是编译期常量（不可调）
grep -rn 'MAXSYMLINKS' /usr/include/linux/limits.h
# #define MAXSYMLINKS 40

# 这也解释了 03 篇的另一件事：为什么硬链接不能指向目录
#   软链接成环有【可数的跟随层数】作为兜底
#   硬链接成环没有任何计数器能发现 -> 内核直接禁止

struct vfsmount {
    struct dentry *mnt_root;        // 这个文件系统的根 dentry
    struct super_block *mnt_sb;     // 对应的超级块
    int mnt_flags;                  // MNT_NOSUID / MNT_NODEV / MNT_NOEXEC / MNT_READONLY
};
struct mount {                      // 内部结构（fs/mount.h）
    struct mount *mnt_parent;       // ✅ 父挂载
    struct dentry *mnt_mountpoint;  // ✅ 挂在【哪个 dentry】上
    struct vfsmount mnt;
    struct list_head mnt_mounts;    // 子挂载列表
    int mnt_id;
    struct mnt_namespace *mnt_ns;   // ✅ 属于哪个 mount namespace（容器基础）
    ...
};

# 现象回顾
sudo mkdir -p /data && echo "重要数据" | sudo tee /data/important.txt
sudo mount /dev/sdb1 /data
ls /data          # 空的！important.txt 不见了
sudo umount /data
ls /data          # 又回来了

# 所以「用 bind mount 从另一个位置访问被遮盖的内容」是完全合理的
sudo mount --bind / /mnt/rootfs
#          ^^^^^^ 把根文件系统在另一个 dentry 上再挂一次
sudo ls /mnt/rootfs/data          # ✅ 能看到被遮盖的原始内容
#         ^^^^^^^^^^^^ 这条路径解析时不会经过 /data 那个跳板
sudo du -sh /mnt/rootfs/data
sudo umount /mnt/rootfs

sudo mount --bind /data/www /var/www
# 内核做的事：创建一个新的 struct mount，
#   mnt_mountpoint = /var/www 的 dentry
#   mnt_root       = /data/www 的 dentry      ← 关键：指向【已有的】dentry
#   mnt_sb         = 与源相同的 super_block
# 所以它不是拷贝，而是「同一份 inode 树的第二个入口」

# 验证：bind mount 的两边是同一个 inode
sudo mount --bind /data/www /var/www
stat -c '%i %d' /data/www /var/www
# 2621500 2049
# 2621500 2049                    <- inode 和设备号都相同

findmnt /var/www
# TARGET   SOURCE            FSTYPE OPTIONS
# /var/www /dev/sdb1[/www]   ext4   rw,relatime
#                    ^^^^^^ 方括号里显示「源是该文件系统里的哪个子目录」

# 只读 bind mount 需要两步（11 篇 5.4 提过）
sudo mount --bind /data/config /app/config
sudo mount -o remount,bind,ro /app/config
# 原因：bind 时的 ro 在老内核上不生效 —— 因为第一步只是建立跳板，
#      挂载标志（MNT_READONLY）要在第二步才能设到新的 struct mount 上

findmnt -o TARGET,PROPAGATION | head
# TARGET  PROPAGATION
# /       shared
# /proc   shared

# 四种传播类型
sudo mount --make-shared /mnt/a      # shared：双向传播（A 下面挂新东西，B 也能看到）
sudo mount --make-private /mnt/a     # private：不传播（默认）
sudo mount --make-slave /mnt/a       # slave：单向接收（上游的变化会传下来，反之不会）
sudo mount --make-unbindable /mnt/a  # unbindable：不能被 bind

# 为什么需要这个机制？
# 场景：容器里挂载了宿主机的 /media，宿主机插了 U 盘自动挂到 /media/usb
#   shared  -> 容器里也能看到 /media/usb（数据共享场景需要）
#   slave   -> 容器能看到宿主的挂载，但容器内的挂载不影响宿主（K8s 的默认行为之一）
#   private -> 完全隔离（安全，但共享存储场景不方便）

# K8s 的 volume mountPropagation 就是这三种：
#   None（private）/ HostToContainer（slave）/ Bidirectional（shared）

# 每个进程属于某个 mount namespace
ls -l /proc/self/ns/mnt
# lrwxrwxrwx ... /proc/self/ns/mnt -> 'mnt:[4026531840]'
#                                          ^^^^^^^^^^ namespace 的 inode 号

# 对比宿主与容器的挂载树
sudo readlink /proc/1/ns/mnt
sudo readlink /proc/$(docker inspect -f '{{.State.Pid}}' mycontainer)/ns/mnt
# 数字不同 = 不同的 namespace = 不同的挂载树

# 手动创建一个（不需要容器运行时）
sudo unshare --mount --propagation private bash
# 现在在新的 mount namespace 里
mount -t tmpfs tmpfs /mnt              # 这个挂载【只在这个 namespace 里可见】
findmnt /mnt
exit
findmnt /mnt                           # 宿主机上看不到 ✅

# 进入某个容器的挂载视图（15 篇用过同样的技巧看网络）
sudo nsenter -t <PID> -m findmnt
sudo nsenter -t <PID> -m --wd=/ ls /

// procfs 的每个文件注册一个 show 函数
// fs/proc/meminfo.c
static int meminfo_proc_show(struct seq_file *m, void *v)
{
    struct sysinfo i;
    si_meminfo(&i);
    seq_printf(m, "MemTotal:       %8lu kB\n", ...);   // ← 读的瞬间才生成文本
    ...
}

ls -l /proc/meminfo
# -r--r--r-- 1 root root 0 Aug 12 14:00 /proc/meminfo
#                        ^ 大小是 0，因为内容还不存在！
wc -c /proc/meminfo                    # 但 cat 出来有上千字节
df /proc                               # 大小 0 —— 不占任何磁盘

# 更有意思的是：有些 proc 文件不支持部分读
dd if=/proc/meminfo bs=10 count=1 2>/dev/null | wc -c
# 结果可能不是 10 —— seq_file 的语义与普通文件不同（18 篇讲的语义泄漏）

# sysfs 的每个文件对应一个 kobject 的属性，有 show/store 两个回调
cat /sys/class/net/eth0/mtu            # 调用 show 回调
echo 1400 | sudo tee /sys/class/net/eth0/mtu    # 调用 store 回调
#                                                  ^^ 这就是 15 篇 ip link set mtu 的另一条路径

# sysfs 的组织是「一个属性一个文件」，这是有意的设计（对比 ioctl）
ls /sys/block/sda/queue/
# scheduler  rotational  nr_requests  read_ahead_kb  max_sectors_kb ...
#            ^^^^^^^^^^ 11 篇用它判断 SSD/机械盘
# 好处：可发现（ls 就知道有哪些参数）、可脚本化、有独立的权限控制
#      —— 正是 18 篇 2.3 说的「ioctl 的结构化替代方案」

# tmpfs 的实现极简：文件数据【直接】就是 page cache 里的页，没有后备存储
findmnt /dev/shm
# /dev/shm tmpfs tmpfs rw,nosuid,nodev

# 所以：
#   ✓ 极快（没有磁盘 I/O）
#   ✓ 可以被 swap 出去（与 ramdisk 的关键区别）
#   ✗ 占的是内存（11 篇 3.4 讲的「往 /tmp 写大文件会吃内存」）

# 常见的 tmpfs
findmnt -t tmpfs -o TARGET,SIZE,USED
# /run        1.6G   1.2M      <- 03 篇讲的 pid 文件与 socket
# /dev/shm    7.8G   0         <- POSIX 共享内存
# /tmp        7.8G   12M       <- 部分发行版
# /sys/fs/cgroup ...

# 容器的根文件系统就是一个 overlay 挂载
findmnt -t overlay
# TARGET SOURCE  FSTYPE  OPTIONS
# /      overlay overlay rw,lowerdir=/l1:/l2:/l3,upperdir=/u,workdir=/w

# 手动做一个（理解镜像分层）
mkdir -p /tmp/ov/{lower1,lower2,upper,work,merged}
echo "from lower1" > /tmp/ov/lower1/a.txt
echo "from lower2" > /tmp/ov/lower2/a.txt      # 同名文件
echo "only in lower2" > /tmp/ov/lower2/b.txt
sudo mount -t overlay overlay \
     -o lowerdir=/tmp/ov/lower1:/tmp/ov/lower2,upperdir=/tmp/ov/upper,workdir=/tmp/ov/work \
     /tmp/ov/merged

cat /tmp/ov/merged/a.txt        # from lower1     <- 靠前的 lower 优先（镜像层的覆盖语义）
cat /tmp/ov/merged/b.txt        # only in lower2
echo "modified" > /tmp/ov/merged/a.txt           # 写入 -> 触发 copy-up
ls /tmp/ov/upper/                # a.txt          <- ✅ 被复制到 upper 层再修改
cat /tmp/ov/lower1/a.txt         # from lower1    <- 下层【未被修改】
rm /tmp/ov/merged/b.txt
ls -l /tmp/ov/upper/b.txt        # c--------- ... <- ✅ whiteout：用字符设备标记「已删除」
sudo umount /tmp/ov/merged

# FUSE 是 18 篇讲的「宏内核里的微内核思想」
ls -l /dev/fuse

# 工作方式：
#   ① 内核的 fuse 模块注册成一个文件系统类型
#   ② 用户态守护进程通过 /dev/fuse 与内核通信
#   ③ 应用的 read() -> VFS -> fuse 模块 -> 【转发给用户态进程】-> 结果返回

# 常见的 FUSE 文件系统
sshfs user@host:/remote /mnt/remote      # 通过 SSH 访问远程目录（16 篇）
rclone mount remote:bucket /mnt/cloud    # 对象存储当文件系统
gocryptfs /enc /mnt/plain                # 加密目录
s3fs mybucket /mnt/s3

# 代价：每次 I/O 要多两次用户态↔内核态切换 + 数据拷贝
#      → 性能远低于内核态文件系统（这正是 18 篇讲的微内核 IPC 开销）
findmnt -t fuse.sshfs

# 观察 VFS 层的锁竞争（元数据密集负载下）
sudo perf top -e 'lock:*' 2>/dev/null | head
sudo perf record -g -- bash -c 'for i in {1..20000}; do touch /tmp/many/f$i; done'
sudo perf report | head -20
# 能看到 inode_lock、d_lock 这类符号占比

# 对比：同目录并发创建 vs 分散到多目录
mkdir -p /tmp/bench1 /tmp/bench2/{a,b,c,d}
time (for i in $(seq 1 5000); do touch /tmp/bench1/f$i; done)
time (for i in $(seq 1 5000); do touch /tmp/bench2/$((i%4==0?"a":i%4==1?"b":i%4==2?"c":"d"))/f$i 2>/dev/null; done)
# 大量小文件的场景下，「分散到多个目录」通常更快