问题标签 [block-device]

我正在研究一个 Linux 内核模块，该模块要求我在将数据写入本地磁盘之前检查数据。要写入的数据是从远程磁盘获取的。因此，我知道 fetch 中的数据存储在页面缓存中。我还知道 Linux 有一个数据结构，可以管理运行中的块 I/O 请求，称为 bio 结构。

bio 结构包含一个称为 bio_vecs 的结构列表。

它有一个列表，因为内存中的块表示可能在物理上不连续。我想要做的是使用 bio_vecs 列表抓取缓冲区的每一块并将它们放在一起，以便我可以获取块的 MD5 哈希。如何使用指向页面的指针、缓冲区的长度及其偏移量来获取缓冲区中的原始数据？是否已经有此功能，还是我必须自己编写？

大多数用户空间进程在单元运行大约 3-4 天后进入 D 状态，该单元在 ARM 处理器上运行。从顶部 o/p 我们可以看到处于 D 状态的进程正在等待系统调用“page_fault”和“squashfs_readpage”。最终这会导致看门狗复位。进入 D-sate 的过程需要非常长的时间才能恢复。

以下是系统最终出现故障时的顶级 o/p：

一个更有趣的观察是，当系统陷入这个问题时，我们可以始终看到“mtdblockd”进程在顶部 o/p 中运行。我们在这个单元上禁用了交换。单元中没有明显的内存泄漏。

知道可能的原因是什么，这些过程卡在 D 状态吗？

如果我只知道设备名称是“\.\PhysicalDrive0”并且上面没有文件系统或卷标，如何从 Windows 中的块设备或原始磁盘获取大小？

我尝试了以下方法：

fd = os.open(r"\.\PhysicalDrive0", os.O_RDONLY)

os.lseek(fd, 0, os.SEEK_END)

它在 Linux 上运行良好，但在 Windows 上总是返回“OSError: [Errno 22] Invalid argument”。

我也尝试了 ctypes.windll.kernel32.GetDiskFreeSpaceExW()，但它似乎只适用于具有文件系统和分配卷标的磁盘。

对原始磁盘或块设备执行此操作的正确方法是什么？

提前致谢。

我正在 Linux 内核和 make_request 例程中编写自定义块驱动程序，在写入新数据之前，我需要读取 bio 指定扇区的数据（从物理驱动器）。我下面的摘录展示了我想要完成的大部分工作，但无论出于何种原因，我从未从 wait_for_completion 中得到回报。一旦对块设备执行 I/O。它在 submit_bio 之后挂起并且永远不会继续。每 120 秒我都会收到一个堆栈转储和消息，说明任务是如何被阻止的。有任何想法吗？想法？

我知道我可以像这样用 0x0 填充整个磁盘：

有没有办法用我选择的字符填充整个磁盘？

我的任务是使用 Python 复制大量文件。目前我已经完成了所有设置，复制整个目录树工作正常。但我陷入了复制管道和块文件的困境。如何仅使用 Python 复制这样的文件？甚至可能吗？

我有一个在商业产品中工作了一年多的块设备驱动程序。REQ_DISCARD最近，我尝试通过启用丢弃和处理带有标志的请求来添加对精简配置的支持。每当我blk_end_request从任何上下文调用这些类型的请求的任何变体时，我似乎最多只能得到一个BUG()输出，最坏的情况是挂起或糟糕（变体包括以 .blk_end_request_all为前缀的未锁定版本__）。此外，似乎当我尝试以这种方式完成请求时（这对于正常的读/写请求工作正常），上面的文件系统驱动程序 ext4REQ_DISCARD有时即使使用相同的请求指针也会重新发出相同的请求。这是一个简化的请求函数（传递给blk_init_queue) 来说明问题。这大约在我可以转过请求的时候，所以它消除了我几乎所有的代码，这又适用于正常的读/写。

这些请求是否有一些需要从根本上不同的处理方式？我尝试查看其他驱动程序，例如 sd、md、xenblk 等……但它们完全不同，所以不清楚。我想最根本的问题是你如何正确处理 REQ_DISCARD 请求并通知/发出完成的信号？

如果这是一个已知错误，我的内核版本由 uname -a 报告是Linux mydevbox 3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

问题是当我无法挂载设备但我可以访问（读取）设备上的任何 LBA 时，如何识别驻留在设备 (LUN) 上的文件系统类型是什么。

我正在寻找类似的东西：NTFS 将其文件系统类型保留在 LBA 编号上X，ext3 将其文件系统类型保留在 LBA 编号上Y。

我想知道的主要 FS 是：NTFS、ext3、ext4 和 VMFS。

该环境是一个 linux 机器，可以使用dd命令从设备访问块。

谢谢您的帮助。

我正在尝试使用BUSE（带有 NBD）在用户空间中创建块设备。创建文件系统时，我并不清楚块访问模式。如示例所示，当我挂载 nbd 设备并创建块大小为 4096 的 ext4 文件系统时，我看到读取和写入是 1024 的倍数，而不是 4096。

但是，一旦创建了文件系统，当我挂载设备并尝试读/写文件时，请求将以 4096 的倍数发送。

所以看起来，在使用 mkfs.ext4 创建文件系统时，块设备以 1024 作为块大小访问，只有在文件系统创建后，才会使用用户指定的块大小。我做出这个推断是否正确？如果是这样，有人可以解释后端发生了什么以及为什么最初选择 1024 吗？

谢谢并恭祝安康，

沙拉特

I am trying to understand and modify the Linux network block device driver (/drivers/block/nbd.c).

When the device gets a read request, I am logging the 'bi_sector' of the bio structs that is part of this request.

For example, I am getting 7860224 as the sector number for a bio struct. From reading documentation about bio struct, I have an understanding that this sector number is the hardware starting sector number where this bio will start the operation. I am also printing the data contained in the single physical page in the single bio_vec in this bio. I am able to see the contents of the file I am actually reading.

Now, I am replacing few characters in the file and then saving the file. The write request comes to the driver and I want to log the bi_sector for the write bio struct. I am expecting that it should be same as the previous one - 7860224. However that is not the case. I am getting the sector number as 7880704. Now if I read the file again, I am getting 7880704 as the sector number. I am not sure what is happening. My understanding is that if I am writing the same block that I read, then I should see the same sector number in the bio struct. Is this understanding flawed?