问题标签 [block-device]

我读过未对齐大小的块的写入会导致额外的读取。我的意思是在 Linux 中的块设备上写入。为什么？我怎么能看到它？

考虑系统中的一个设备，在 /dev/hdd[sg][nvme]xx 下打开设备，获取文件描述符并开始使用它（read(v)/ write(v)/lseek等），在某些时候你可能会得到EIO. 您如何检索设备驱动程序报告的基础错误？

EDIT001：如果无法使用unistd函数，也许还有其他方法可以使用块设备来提供更多低级信息，例如sg_scsi_sense_hdr？

我得到以下输出udevadm info -q property -n /dev/sda

输出最后一行的 USEC_INITIALIZED 属性是什么。

它只是连接设备和设备实际初始化之间的时间吗？

此外，如果是初始化时间，内核将如何知道设备何时被初始化，因为对于不同类型的设备（例如：块设备、相机等），它将以不同的方式完成。

我们正在使用 CloudFormation 创建一EC2台使用的机器AWS::AutoScaling::LaunchConfiguration，但我们从未真正指定BlockDeviceMapping要使用的机器：

官方文档声明不是必需的BlockDeviceMappings，但它没有说明当我们不指定时默认值是什么。

BlockDeviceMappings未填写属性时，默认创建的 EBS是什么？

我有一个关于 Linux 内核处理文件 I/O 的一般性问题。目前我的理解是，在理想情况下，进程A读取文件后，数据被加载到页面缓存中，如果进程B在回收之前读取了相同的页面，则不需要再次访问磁盘。

我的问题与块设备 I/O 的工作方式有关。进程 A 的读取请求最终将在 I/O 实际发生之前排队。现在如果要将设备 B 的请求（一个bio结构体）插入到 中request_queue，在执行 A 的请求之前，电梯会考虑是否将 B 的请求合并bio到任何现有的request中。现在，如果 A 和 B 尝试读取相同的文件偏移量，即相同的设备块，它们实际上是相同的 I/O，（或者 A 和 B 的请求不完全相同，但它们对于某些块重叠），但到目前为止我还没有在内核代码中看到这种情况。（我看到的唯一相关的事情是测试是否bio可以粘到现有的request连续。）

内核 2.6.11

内核 5.3.5

这是否意味着内核只会执行两个 I/O？或者（很可能）我错过了什么？

谢谢！

我们知道基于“vtable”原理的接口。一旦有了指向对象的指针，就可以将其缩小到接口，新对象是同一个对象，但仅限于接口。我一直认为硬件固件有点相似。例如，对于块设备（HDD 或 SSD），此接口类似于read、write、status等。所以驱动程序就是这样一个设备接口的用户。

事实证明，任何存储设备都有固件和一个标记为内部的特殊存储区域，用于保存固件。制造商发布的程序允许“闪存”他们的特定设备，例如通过将新程序写入其内部空间，对操作系统隐藏。

我的问题是：在软件级别上，他们如何对驱动器的“隐藏”区域执行这种读写操作？死的“COM端口”有什么关系？

如果 HDD 可以在所有操作系统上运行，为什么固件升级软件只针对 Windows 发布？在 linux 的开源世界中，我需要阅读哪些内容才能更好地理解“调试固件”？

我有一个关于SCSI层中的多队列 (MQ)以及iSCSI的问题。显然有很好的技术和科学文献解释了块层级别的多队列（MQ）。但是很少有任何好的解释来说明这个多队列 (MQ) 是如何触发到 SCSI 层然后是 iSCSI 的。AFAIK，自 Linux 内核 3.13 (2014) 起，linux 块层具有多队列又名mq-blk。在块层mq-blk之后，必须更新SCSI IO 提交路径。因此，SCSI 多队列又名scsi-mq工作自 Linux 内核 3.17 起就可以正常工作。因此，我有以下问题：

问题1： SCSI层实际上是如何实现多队列的？

问题 2：传统上，SCSI 中层用于创建queuecommand()。现在在 SCSI 中实现多队列时，多队列实际上是否意味着创建多个queuecommand ()？

问题 3：在 SCSI 代码库中究竟哪里可以看到多队列？

问题 4：一旦我们在 SCSI 中实现了多队列，这在 iSCSI 级别是如何实现的？

请帮助我理解它。

我有一个模拟 ARM vexpress-a9 的工作 QEMU 映像，我像这样运行它：

sudo qemu-system-arm -m 512M -M vexpress-a9 -D qemu.log -d unimp -kernel buildroot-2019.02.5/output/images/zImage -dtb buildroot-2019.02.5/output/images/vexpress-v2p-ca9.dtb -append "console=ttyAMA0,115200 kgdboc=kbd,ttyAMA0,115200 ip=dhcp nokaslr" -initrd buildroot-2019.02.5/output/images/rootfs.cpio -nographic -net nic -net bridge,br=mybridge -s

我现在想为持久存储添加一个硬盘，然后将控制权从基于busybox initrd 的rootfs 转移到Linux 提供的完整版本。所以我将它添加到命令行

sudo qemu-system-arm -m 1024M -M vexpress-a9 -D qemu.log -drive if=none,format=raw,file=disk.img -kernel buildroot-2019.02.5/output/images/zImage -dtb buildroot-2019.02.5/output/images/vexpress-v2p-ca9.dtb -append "console=ttyAMA0,115200 kgdboc=kbd,ttyAMA0,115200 ip=dhcp nokaslr" -initrd buildroot-2019.02.5/output/images/rootfs.cpio -nographic -net nic -net bridge,br=mybridge -s

当然，我首先创建一个磁盘映像并将其格式化为 ext2： qemu-img create disk.img 10G && mkfs.ext2 -F disk.img

从日志消息中我看到它根本无法检测到这一点。有人可以总结块设备如何与 Qemu 一起工作。我知道旧的-hda已经改成新的-drive选项，可以分别结合前后端的繁琐规范。但我不知道基础知识以及为什么会遇到这个问题。

我基本上是在寻找switch_root从 initrd 到成熟的 Linux rootfs，但这只是第一步。

正如我们所知，在 docker 中存在类似 storage-driver（如 devicemapper、overlay2 等）的东西。存在一些我不明白的事情：
容器可以访问卷或它自己的文件系统。

docker存储驱动程序怎么可能拦截这样的I/O访问请求？毕竟，存储驱动的代码必须完成工作，但是容器就像进程一样，所以请求应该由操作系统处理。另一方面，这些请求必须由存储驱动程序处理（毕竟，它可能需要深入到更深层等等）。

这是否意味着每个 I/O 请求都是由存储驱动程序处理的？这怎么可能？对卷的访问呢？

我正在使用带有Ceph 13.2.2 模拟集群的kubernetes v1.16.10通过 ceph -csi进行动态卷配置。

但后来我找到了 ceph-rbd

Ceph RBD (kubernetes.io/rbd)

https://kubernetes.io/docs/concepts/storage/storage-classes/#ceph-rbd

根据：

Ceph CSI (rbd.csi.ceph.com)

https://docs.ceph.com/docs/master/rbd/rbd-kubernetes/#block-devices-and-kubernetes

您可以在 Kubernetes v1.13 及更高版本中通过 ceph-csi 使用 Ceph 块设备映像，它动态地提供 RBD 映像以支持 Kubernetes 卷并将这些 RBD 映像映射为工作节点上的块设备（可选地挂载映像中包含的文件系统）运行引用 RBD 支持的卷的 pod。

那么......我应该使用哪一个？

优点缺点？

提前致谢。