hdparm -g仅显示硬盘物理几何参数（chs或lba总数），不支持文件路径，无法查询文件扇区占用；定位文件物理位置应使用filefrag（ext系列）或debugfs，注意块大小与扇区单位换算。
Linux下hdparm -g不能查文件扇区占用，它只读硬盘几何参数
hdparm -g输出的是整块物理磁盘的“CHS（柱面/磁头/扇区）”或LBA总扇区数，和具体文件完全无关。想查某个文件占用了哪些扇区，hdparm -g连边都摸不到——它压根不接受文件路径参数，也不访问文件系统结构。
常见误用现象：hdparm -g /dev/sda1 或 hdparm -g myfile.txt，前者报错“Operation not supported”，后者直接提示“no such device”。因为-g只能作用于块设备节点（如/dev/sda），且现代SATA/SSD大多已禁用CHS逻辑，返回值常为虚拟值，参考意义极低。
真正能定位文件物理扇区的命令是filefrag和debugfs
filefrag是用户态最轻量、最常用的方法，适用于ext2/3/4文件系统：
- 运行
filefrag -v filename，输出中physical_block列即为起始扇区号（注意：单位是文件系统块，不是512字节扇区；需结合tune2fs -l /dev/sdXN | grep "Block size"换算） - 若显示
extents为1，说明文件连续；大于1表示碎片化，每段有独立physical_block - 对硬链接或稀疏文件要小心：
filefrag报告的是数据块位置，不包含元数据（如inode本身位置）
更底层可上debugfs（需卸载文件系统或只读挂载）：
-
debugfs -R "stat <inode_num>" /dev/sdXN</inode_num>→ 查看该inode所有直接/间接块编号 - 再用
dumpe2fs -h /dev/sdXN拿到First data block和Block size，推算出对应LBA扇区：LBA = (block_num × block_size) ÷ 512 + first_data_block × (block_size ÷ 512)
为什么hdparm -g在NVMe/SSD上基本失效
NVMe设备根本不支持CHS寻址，执行hdparm -g /dev/nvme0n1会直接返回HDIO_GET_GEO: Invalid argument。即使SATA SSD返回了数值，那也是固件模拟的兼容值，和真实NAND闪存映射完全脱钩——FTL（闪存转换层）会动态重映射LBA到物理页，操作系统看到的“扇区”早已不是物理位置。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
所以：
- SSD/NVMe上谈“文件占哪几个扇区”本身是个伪命题，物理位置随时可能被TRIM、GC或磨损均衡改变
- 只有机械硬盘（HDD）+ ext4 + 禁用
discard时，filefrag结果才相对稳定 - 若真需跟踪写入落点（如性能分析），应改用
blktrace+btt抓I/O轨迹，而非静态扇区查询
别忽略文件系统层与块设备层的单位混淆
这是最容易翻车的点：文件系统块（如4096字节）≠ 硬盘扇区（传统512字节或4K原生）。例如filefrag说某段从block 1000开始，而tune2fs显示block size=4096，则对应LBA扇区起点是(1000 × 4096) ÷ 512 = 8000，再叠加First data block偏移（比如1，即额外+8个扇区）。
验证方法：
- 用
dd if=/dev/zero of=testfile bs=4096 count=1创建单块文件 -
filefrag -v testfile记下physical_block -
fdisk -l /dev/sdX确认分区起始扇区（如2048），再查该分区文件系统First data block（通常为0或1） - 手动算出LBA，再用
dd if=/dev/sdX bs=512 skip=XXX count=1 | hexdump -C比对是否为testfile内容
没做单位换算就直接把filefrag的block号当扇区号去dd，八成读到的是别的文件甚至元数据。
