CHS与LBA是磁盘寻址的两种方式，CHS为物理三维坐标，LBA为其线性映射；现代系统仅用LBA，由固件或驱动完成转换，文件系统如ext4直接基于LBA分配数据块。
磁盘物理结构决定寻址方式：CHS 和 LBA 是什么关系？
Linux 文件系统不直接操作磁盘的物理表面，但它的底层设计必须适配磁盘的硬件组织逻辑。机械磁盘（HDD）由多个盘片、磁头、磁道、扇区和柱面构成，而定位任意一个 512字节 的扇区，传统上靠 CHS（柱面-磁头-扇区）三维坐标——比如 C=100, H=3, S=12。现代驱动固件早已把这套映射转为线性地址 LBA（Logical Block Address），操作系统只跟 LBA 打交道。
关键点在于：ext4 等文件系统分配数据块时，用的不是 CHS，而是从 0 开始编号的 LBA 块号；但内核 I/O 子系统最终仍需通过设备驱动将 LBA 转回 CHS（或由 SSD/NVMe 控制器内部再转译）。如果你在 dmesg 里看到 "I/O error on device sda, logical block 0x1a2b3c"，那个十六进制数就是 LBA。
- 不要手动算 CHS → LBA 公式（
LBA = C × H × S + H × S + (S−1)），BIOS/固件已封装；但调试磁盘坏道时，hdparm --read-sector或dd if=/dev/sda of=/dev/null bs=512 skip=123456依赖的就是 LBA 偏移 - SSD 虽无物理磁道，但仍模拟 LBA 接口，所以文件系统层无需修改；但“写放大”“磨损均衡”等行为发生在固件层，
ext4不知情 -
/sys/block/sda/queue/logical_block_size查到的未必是 512 —— 很多新盘标称4096（4K 扇区），此时一个逻辑块 = 8 个传统扇区，fdisk对齐错误会导致性能暴跌
文件系统如何把“文件”变成磁盘上的块？inode 是核心枢纽
你在 ls -li 看到的第一列数字，就是 inode 编号。它不是文件名，而是指向一个固定大小（通常 256 字节）元数据结构的指针。这个结构里存着：文件类型、权限、所有者、时间戳、链接数，最关键的是——指向实际数据块的指针列表。
也就是说，/home/user/doc.txt 这个路径只是目录项（dirent）里的一个名字+inode号映射；真正读取内容时，内核先查目录找到 inode 号，再查 inode table 拿到数据块编号，最后去对应 LBA 位置读取。
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
- 小文件（≤60 字节）可能直接塞进 inode 里（
ext4支持 inline data），不占额外数据块 - 大文件用三级间接块：直接块（12 个）、一次间接块（指向块表）、二次间接块（指向块表的块表）……层级越多，访问延迟越高
-
stat /path/to/file显示的Blocks:是按 512 字节单位统计的，和du -b不同；而文件系统分配是以block size（如 4096）为单位，ls -l显示的大小 ≠ 占用空间
超级块、块组、位图：文件系统怎么管理“空闲”与“已用”？
整个分区格式化成 ext4 后，开头第一个块就是 superblock，它记录了总块数、空闲块数、块大小、inode 总数等全局信息。但只靠一个超级块太危险——损坏就全盘崩溃。所以 ext4 在每个 block group（默认每 16384 个块一组）开头都备份一份超级块，并附带该组的 inode bitmap 和 block bitmap。
这两个位图就是开关阵列：每个 bit 对应一个 inode 或一个数据块，“1”表示已用，“0”表示空闲。创建文件时，文件系统扫描位图找第一个 0，设为 1，再更新超级块里的空闲计数。
-
dumpe2fs -h /dev/sda1看超级块摘要；dumpe2fs -x /dev/sda1可导出位图二进制，但一般没必要——e2fsck -n就能检查一致性 - 删除文件 ≠ 清空数据块，只是把 inode 标记为未用、对应位图 bit 置 0；原数据还在，直到被新文件覆盖——这就是恢复工具（如
extundelete）的原理 - 频繁小文件写入容易导致位图碎片化，
ext4默认启用flex_bg（弹性块组）缓解，但 SSD 上影响不大
挂载与 VFS：为什么 /proc 和 /sys 看起来像文件却不在磁盘上？
Linux 用虚拟文件系统（VFS）抽象所有存储后端：无论是真实磁盘上的 ext4、网络存储的 nfs，还是纯内存的 tmpfs，都统一提供 open()/read()/write() 接口。而 /proc 和 /sys 是典型的伪文件系统（procfs、sysfs），它们根本没数据块，每次 cat /proc/meminfo 都是内核现场拼字符串返回。
这解释了为什么 df 显示 /proc 占用 0 字节，而 ls /proc 却能看到几百个“目录”——它们是内核数据结构的实时投影，不是磁盘映射。
-
mount -t proc proc /proc是必需步骤，否则/proc下为空；但多数发行版启动时自动完成 - 你不能对
/proc/sys/net/ipv4/ip_forward执行ln -s，因为它是只读接口；写入生效靠echo 1 > ...触发内核回调，不是改磁盘 -
/dev下的设备文件（如/dev/sda）也不是磁盘内容，而是内核设备模型的入口节点，访问它会触发驱动程序，而非读块设备
data=ordered vs data=writeback）、日志何时刷写（jbd2）、甚至 CPU 缓存行对齐是否影响 inode 访问效率。这些细节不常暴露，但一旦出问题（如断电后 ext4 报错 requiring fsck），根源几乎都在元数据与物理块映射的衔接环节。 
