Linux内核-以编程方式检索被写入的块号 [英] Linux Kernel - programmatically retrieve block numbers as they are written to

问题描述

我想维护一个块号列表，因为它们是使用Linux内核源代码实际写入的.我打算修改内核源代码来做到这一点.我只需要在内核源代码中找到处理写入物理分区的结构和功能，并在它们写入物理分区时获取块号即可.

I want to maintain a list of block numbers as they are physically written to using the linux kernel source. I plan to modify the kernel source to do this. I just need to find the structure and functions in the kernel source that handle writing to physical partitions and get the block numbers as they write to the physical partition.

有什么办法吗?任何帮助表示赞赏.如果我可以找到内核实际在哪里写入分区并返回块号，那将是可行的.

Any way of doing this? Any help is appreciated. If I can find where the kernel is actually writing to the partitions and returning the block numbers, that'd work.

推荐答案

这不仅仅是一个检查的地方.例如，如果块设备是iSCSI或AoE目标，那么您将寻找它们各自的驱动程序，然后最终在另一端找到相同的驱动程序.

It isn't just one place to check. For instance, if the block device was an iSCSI or AoE target, you would be looking for their respective drivers, then ultimately the same on the other end.

对于普通的SCSI，杂项闪存设备等，减去网络交互，同样如此.

The same would go for normal SCSI, misc flash devices, etc, minus network interaction.

VFS只是在方便，统一和一致的接口中将所有这些内容组合在一起，以使read()和write()之类的调用在提供缓冲的同时起作用.实际的魔术(包括排序和写入障碍)由块dev驱动程序本身处理.

VFS just pulls these all together in a convenient, unified and consistent interface for calls like read() and write() to work while providing buffering. The actual magic, including ordering and write barriers are handled by the block dev drivers themselves.

在使用设备映射器的情况下，路径会稍有变化.它来自vfs-> dm_(target)-> blockdev_driver.

In the case of using device mapper, the path alters slightly. It goes from vfs -> dm_(target) -> blockdev_driver.

这篇关于Linux内核-以编程方式检索被写入的块号的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！