裸设备和字符设备有区别吗？

thesix

不错不错，概念越讨论越清楚。

>> 裸设备raw lv即是直接与driver打交道

正确。

>> 单次I/O必须是512-byte 对齐的，所以传输大小至少是512字节的整数倍。

对于 LVM 来讲，这个限制是由于 LVM 在底层统一采用了 Block I/O 的读写方式。换句话说，不管你是通过字符设备还是块设备访问 LVM，最终都会以 Block I/O 的方式传递数据，而这种方式的确要求I/O到达LVM 时它的大小为 block size (512字节) 的整数倍。

但通过字符设备和块设备访问 LVM的本质区别在于：

1. 块设备虽然表面上可以接受‘不定长’的‘逻辑’请求（例如 dd bs=1），但它必须经过块缓存（block buffer）模块才能达到LVM I/O 模块，而块缓存I/O必然是以“一个” 512字节块进行的（不能大，也不能小）。所以，在LVM这一层发生的还是512字节的读写。当你写1字节的时候，块缓存模块必须先把当前的512字节从LV里读出来，更新一个字节以后再把整个512字节写回去。如果你读写1KB，块缓存必须把它分成两个512字节的请求发个LVM。所以在LVM层实际发生了两个512字节的读写。

2. 字符设备从定义上支持不定长存取。但由于 LVM 底层实现采用了block I/O 的方式，I/O 必须以 512字节 的整数倍进行，并且单个I/O 大小不能大于 LTG (缺省128KB)。由于不经过缓存模块的‘打包’，1字节的请求不能在到达LVM底层时变成512字节，所以LVM返回 EINVAL 的错。但4KB, 8KB 直到 128KB 的请求都会直接处理，不会被分拆成 512字节，这是和块设备的存取方式的本质区别。

>> 反而块设备是利用了系统缓存，可以支持变长I/O的，这正是使用额外缓存带来的灵活度。

如上说述，这个的“灵活度”可以说是一种假象。实际上字符设备才更灵活。

>> 块设备只是一个逻辑上的概念

块设备决定了它的I/O会被块缓存模块聚合或分拆成 512字节，这个逻辑概念对实际应用的影响是实实在在的。

个人认为，在6楼的描述，除了没有指出LVM Block I/O 这个 512字节整数倍的限制外，基本都是正确的。
特别是关于字符及块设备的定义，以及它们对应用的影响。

9 楼以为如何？欢迎继续讨论。

冬瓜头

thesix老兄，我做了一下试验，用块设备的时候，底层io单位总是4K而不是512B，另外，不管上层io size是多大，底层总是4K，永远不会是别的值。这一点在infocenter也正式说明了，不过我不明白为什么要这么做？这个size是在哪一层被限制的？device driver？不会，内核其他什么地方？不知道了。

另外还有一个问题，在比如使用oracel的asm的时候，为何几乎所有配置实例中都是用了hdisk块设备，这样显然不妥吧。。。

Charlemagne

To 12楼：
你的实验做得不错，的确是这样。不过不知道你的实验具体是怎样的？
如果用块设备，底层总是以4K为单位，这个应该是在logical volume device driver里实现的。
个人认为这个4K单位应该与VMM换页有一定关系，因为block lv对应的文件系统都是以pagesize为单位进行换页，这样实现起来最简单。

oracle asm如果选择使用rhdiskX就直接到了disk driver一层，没有经过logical volume driver，自由度更高，如果做得好性能肯定更佳。
当然对于普通的开发者来说，简单才是最重要的。所以用CIO，把fastpath打开就足够了。

To thesix：
我的观点接近于你在11楼+6楼的表述，基本认同你的看法。

---
我没有研究过这方面的源码，所以描述主要基于我从应用层看到的情况以及跟lab开发人员的讨论。如有疏漏，欢迎指正。

[ 本帖最后由 Charlemagne 于 2008-12-21 20:27 编辑 ]

冬瓜头

不仅仅是lv，直接对/dev/hdisk也是这样的，要说hdisk的driver应该是最底层的了，driver层面不会限制4K的，我觉得应该是kernal中更上一层的某处。

另外，可能误会了，我是看到几乎所有asm案例都直接用的/dev/hdisk，而不是/dev/rhdisk或者/dev/rlv，ibm明确推荐使用rlv，连rhdisk都不要使用。所以我奇怪到底是那些案例确实不妥，还是其他原因？

Charlemagne

不至于吧，你google一下oracle 10g online documentation就可以看到ORACLE的安装文档了。
这是从其中取下来的：如果用asm的话，使用的设备都是/dev/rhdisk
system=/dev/rhdisk11
sysaux=/dev/rhdisk12
example=/dev/rhdisk13
users=/dev/rhdisk14
temp=/dev/rhdisk15
undotbs1=/dev/rhdisk16
undotbs2=/dev/rhdisk17
redo1_1=/dev/rhdisk18
redo1_2=/dev/rhdisk19
redo2_1=/dev/rhdisk20
redo2_2=/dev/rhdisk22
control1=/dev/rhdisk23
control2=/dev/rhdisk24
spfile=/dev/dbname_spfile_raw_5m
pwdfile=/dev/dbname_pwdfile_raw_5m

冬瓜头

看来那些用hdisk的果然是野路子了，呵呵。

fck

先顶再看！

anlen.qi

原帖由 yddll 于 2008-6-12 13:36 发表


咋ln了？

informix也可以不用链接，直接在informix配置文件里指定/dev/rrootdbs等参数，
这样省得一道麻烦

thesix

原帖由 Charlemagne 于 2008-12-21 20:14 发表
如果用块设备，底层总是以4K为单位，这个应该是在logical volume device driver里实现的。
个人认为这个4K单位应该与VMM换页有一定关系，因为block lv对应的文件系统都是以pagesize为单位进行换页，这样实现起来最简单。

唉 。。。其实我写完几天后就意识到写错了，应该是4K，不是512B。但最近太忙，没上来改；也觉得迟早有人会注意到这个错误的。

就像你说的，这个确实应该和VMM 的 4K page 单位有关。
其实道理很简单：AIX/POWER 上一个page (4K or larger) 是任何内存输入输出的最小单位，既然是'buffer' ，就逃不过这个‘限制’。
虽然传统上讲'block' = 512B，但落实到实际产品，还是和操作系统和处理器硬件的实现有关。
我不仅没考虑这一点，还莫名其妙地误看测试数据，真是无语。

其实会用 kernel trace 的话，抓一个 dd 的trace， 看看trace report (key word: LVM lstart) 就知道不同情况下底层 I/O 的大小了。