发出从设备驱动程序的下半部分读取的磁盘
在 Xen 设置中，来自来宾 VM 的 IO 访问会通过一个名为 dom0 的特权域，该域只是一个修改后的 Linux 内核，其中包含来自 XEN 虚拟机管理程序的调用。对于块IO，他们有一个分离的驱动程序模型，其前端位于guest VM中，驱动程序的后端位于domain0中。后端只是创建一个“bio”结构并像传统的 Linux 块驱动程序代码中那样调用submit_bio()。
我的目标是检查写入磁盘的数据是否存在任何问题（丢失数据、无提示写入损坏、写入方向错误等）。因此，我需要读取写入磁盘的数据，并将其与缓存中的数据副本进行比较（这是一种称为“写入后读取”的常见磁盘功能）。我的问题是，是否无法从我的后端驱动程序级别调用 __bread() ？调用 __bread 时内核崩溃。有人能理解其中的原因吗？另外，如果这是不可能的，还有什么其他方法可以从驱动程序下半部分的磁盘读取特定的数据块？
我可以拦截并克隆写入的bio结构，并更改在新bio中读取的操作并再次调用submit_bio()吗？我这样做了，但是由submit_bio()的完成回调返回的bio结构中的扇区号是一些随机值，而不是我发送的值。
谢谢。
In a Xen setup, IO accesses from guest VMs go through a privileged domain called dom0 that is just a modified Linux kernel which has calls from and to the XEN hypervisor. For block IO, they have a split driver model whose front-end is in the guest VM and the backend of the driver in the domain0. The backend just creates a 'bio' structure and invokes submit_bio() as in traditional linux block driver code.
My goal here is to check if there is any problem in the data written to disk(lost data, silently corrupted writes, misdirected writes, etc). So I need to read the data that was written to disk and compare it with a on-cache copy of data (this is a common disk function called 'read after write'). My question is, is it not possible to invoke __bread() from my backend driver level ? The kernel crashes when __bread is invoked.. Could anyone understand the reason for this ? Also, if this ain't possible, what other ways are out there to read a specific block of data from disk at the driver's bottom-half ?
Can I intercept and clone the bio structure of the writes, and change the operation as read in my new bio and invoke submit_bio() again ? I did that, but the sector number in the bio structure that is returned by the completion callback of submit_bio() is some random value and not the ones I sent..
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果这是我的任务，我会首先尝试编写一个新的调度算法。首先复制
cfq或deadline或noop或as调度代码，然后从那里开始对其进行处理接受写请求后提交读命令。noop可能是最容易修改为在写入后立即读取并向上传播错误的方法，但我无法想象性能会非常好。但是，如果您使用其他调度程序之一作为基础，则在写入后立即发出错误信号可能会更加困难 - 也许在再次调度读取之前会经过几秒钟 - 所以它实际上只是作为事后诊断有用，而不是可以直接使应用程序受益的东西。If this were my task, I'd try first writing a new scheduling algorithm. Start by copying
cfqordeadlineornooporasscheduling code and start working on it from there to self-submit read commands after accepting write requests.noopwould probably be the easiest one to modify to read immediately after write, and propagate errors upwards, but I can't imagine the performance would be very good. But, if you use one of the other schedulers as base, it would probably be much more difficult to signal an error immediately after the write -- perhaps a few seconds would have elapsed before reads were scheduled again -- so it would really only be useful as a diagnostic after the fact, and not something that could benefit applications directly.