linux内核，struct :页面的读写方式
我正在阅读LDD3并处理内核源代码。目前，我正试图充分理解struct bio及其用法。
到目前为止，我读到的是：
https://lwn.net/images/pdf/LDD3/ch16.pdf
http://www.makelinux.net/books/lkd2/ch13lev1sec3
https://lwn.net/Articles/26404/
(a part of) https://www.kernel.org/doc/Documentation/block/biodoc.txt如果我正确理解，struct bio描述了在块设备和系统内存之间传输某些块的请求。规则是，单个结构bio只能引用一组相邻的磁盘扇区，但是系统内存可以是非连续的，并且可以用<page,len,offset>向量表示，对吗？也就是说，单个结构bio请求读取/写入bio_sectors(bio) (多个)扇区，从扇区bio->bi_sector开始。传输的数据大小受实际设备、设备驱动程序和/或主机适配器的限制。我可以通过queue_max_hw_sectors(request_queue)得到这个限制，对吗？所以，如果我继续提交磁盘扇区中连续的bio，I/O调度器/电梯将把这些bio合并成一个独立的，直到达到这个限制，对吗？
而且，bio->size必须是512的倍数(或相等的扇区大小)，所以bio_sectors(bio)是一个整数，对吗？
此外，这些bio_sectors(bio)扇区将被移到/从系统内存中移出，而内存是指struct pages。由于<page,len,offset>和磁盘扇区之间没有特定的映射，所以我假设隐式bio->bi_io_vec是按顺序或外观服务的。也就是说，第一个磁盘扇区(从bio->bi_sector开始)将被写入/读取到bio->bi_io_vec[0].bv_page，然后是bio->bi_io_vec[1].pv_page等等。对吗？如果是这样的话，bio_vec->bv_len应该总是sector_size的倍数还是512的倍数？既然一个页面通常是4096字节，那么bv_offset是否应该是{0,512,1024,1536,...,3584,4096}中的一个呢？我的意思是，例如，请求100字节在从偏移量200开始的页面上写入有意义吗？
另外，bio.bio_phys_segments的含义是什么，为什么它与bio.bi_vcnt不同？bio_phys_segments被定义为“包含在这个BIO中的物理段的数量”。三重<page,len,offset>不是我们所说的“物理段”吗？
最后，如果struct bio是如此复杂和强大，为什么我们要创建struct bio列表，并将它们命名为struct request，并在request_queue中对它们进行排队？为什么不为存储每个bio_queue的块设备设置一个struct bio，直到它被服务为止？
我有点困惑，所以任何关于文档的答案或提示都是非常有用的！(预先谢谢:)
回答 1
Stack Overflow用户
发布于 2015-08-13 08:43:41
what is the meaning of bio.bio_phys_segments?泛型块层可以合并不同的段。当内存中的页帧和磁盘上相邻的磁盘数据块相邻时，结果的合并操作就会创建一个更大的内存区域，称为物理段。
Then what is bi_hw_segments?在通过专用总线电路处理总线地址和物理地址之间的映射的体系结构上，允许进行另一次合并操作。这种合并操作产生的内存区域称为硬件段。在80x86体系结构上，在总线地址和物理地址之间没有这种动态映射，硬件段总是与物理段重合。
That is, the first disk sectors (starting at bio->bi_sector) will be written from / read to bio->bi_io_vec[0].bv_page then bio->bi_io_vec[1].pv_page etc.
Is that right? If so, should bio_vec->bv_len be always a multiple of sector_size or 512? Since a page is usually 4096bytes, should bv_offset be exactly one of {0,512,1024,1536,...,3584,4096}? I mean, does it make sense for example to request 100bytes to be written on a page starting at offset 200?bi_io_vec包含IO的页面框架。bv_offset是页面框架中的偏移量。在磁盘上实际写入/读取之前，所有东西都映射到扇区，作为扇区中的磁盘事务。这并不意味着长度必须在多个扇区。因此，这将导致未对齐的读/写，由底层设备驱动程序负责。
if a struct bio is so complex and powerfull, why do we create lists of struct bio and name them struct request and queue them requests in the request_queue? Why not have a bio_queue for the block device where each struct bio is stored until it is serviced?请求队列按设备结构排列，并负责刷新。每个块设备都有自己的请求队列。而生物结构是IO的通用实体。如果您将request_queue特性集成到bio中，那么您将创建一个单一的全局bio_queue，并且这个结构太重了。不是个好主意。因此，这两种结构在IO操作的上下文中服务于不同的目的。
希望能帮上忙。
https://stackoverflow.com/questions/31951233
复制相似问题
腾讯云开发者
