问一个关于随机写和顺序写的问题

cTx521 2014-11-24 02:46:31
机械硬盘上的随机读写和顺序读写的差别主要是在磁道寻址和旋转延迟的。
可以参考:http://stackoverflow.com/questions/2100584/difference-between-sequential-write-and-random-write

我想问的是,由程序生成的数据,比如DD urandom产生的数据,是指的数据内容是随机的,还是说它产生的数据在磁盘上的排列是随机的(按照我的理解应该是数据内容的随机性,因为它相对于的是zero数据)。 再比如说FIO产生的random数据和sequence数据。我用fio在ext-fs上生成了两个文件
1. sequence write
fio --directory=./ --direct=1 --rw=write --refill_buffers --norandommap --randrepeat=0 --ioengine=libaio --bs=4k --rwmixread=100 --iodepth=1 --numjobs=1 --group_reporting --name=4ktestwrite --size=1M
debugfs 1.41.12 (17-May-2010)
debugfs: stat <12>
Inode: 12 Type: regular Mode: 0644 Flags: 0x0
Generation: 1938776540 Version: 0x00000000
User: 0 Group: 0 Size: 1048576
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 2056
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x5464409a -- Thu Nov 13 00:24:42 2014
atime: 0x5464409a -- Thu Nov 13 00:24:42 2014
mtime: 0x5464409a -- Thu Nov 13 00:24:42 2014
Size of extra inode fields: 0
BLOCKS:
(0-11):1545-1556, (IND):1557, (12-255):1558-1801
TOTAL: 257

2. random write
fio --directory=./ --direct=1 --rw=randwrite --refill_buffers --norandommap --randrepeat=0 --ioengine=libaio --bs=4k --rwmixread=100 --iodepth=1 --numjobs=1 --group_reporting --name=4ktestwrite --size=1M
Inode: 13 Type: regular Mode: 0644 Flags: 0x0
Generation: 1938776541 Version: 0x00000000
User: 0 Group: 0 Size: 1048576
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 2056
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x54644117 -- Thu Nov 13 00:26:47 2014
atime: 0x54644117 -- Thu Nov 13 00:26:47 2014
mtime: 0x54644117 -- Thu Nov 13 00:26:47 2014
Size of extra inode fields: 0
BLOCKS:
(0-11):24576-24587, (IND):24588, (12-255):24589-24832
TOTAL: 257
也许你发现了,从block来看的话,他们都是连续的块,并没有想象中的随机性,其实不是,同样的第二条命令上我在ext4上试了,出来的结果如下:
debugfs: stat 4ktestrandwrite.0.0
Inode: 14 Type: regular Mode: 0644 Flags: 0x80000
Generation: 337393007 Version: 0x00000000:00000001
User: 0 Group: 0 Size: 1048576
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 2056
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x545f2295:bd451874 -- Sun Nov 9 03:15:17 2014
atime: 0x545f2295:91e0b274 -- Sun Nov 9 03:15:17 2014
mtime: 0x545f2295:bd451874 -- Sun Nov 9 03:15:17 2014
crtime: 0x545f2295:91e0b274 -- Sun Nov 9 03:15:17 2014
Size of extra inode fields: 28
EXTENTS:
(0-3): 34048-34051, (4-5 [uninit]): 34052-34053, (6): 34054, (7 [uninit]): 34055, (8):
34056, (9-10 [uninit]): 34057-34058, (11-13): 34059-34061, (14 [uninit]): 34062, (15-
22): 34063-34070, (23 [uninit]): 34071, (24-27): 34072-34075, (28 [uninit]): 34076, (2
9): 34077, (30 [uninit]): 34078, (31-34): 34079-34082, (35-36 [uninit]): 34083-34084,
(37-39): 34085-34087, (40-41 [uninit]): 34088-34089, (42): 34090, (43 [uninit]): 34091
, (44-45): 34092-34093, (46 [uninit]): 34094, (47): 34095, (48 [uninit]): 34096, (49-5
2): 34097-34100, (53 [uninit]): 34101, (54-62): 34102-34110, (63 [uninit]): 34111, (64
): 34112, (65 [uninit]): 34113, (66): 34114, (67 [uninit]): 34115, (68-75): 34116-3412
3, (76 [uninit]): 34124, (77-80): 34125-34128, (81 [uninit]): 34129, (82-83): 34130-34
131, (84-87 [uninit]): 34132-34135, (88): 34136, (89 [uninit]): 34137, (90): 34138, (9
1 [uninit]): 34139, (92-95): 34140-34143, (96 [uninit]): 34144, (97-98): 34145-34146,
(99-100 [uninit]): 34147-34148, (101): 34149, (102 [uninit]): 34150, (103-105): 34151-
34153, (106 [uninit]): 34154, (107-110): 34155-34158, (111 [uninit]): 34159, (112): 34
160, (113 [uninit]): 34161, (114-115): 34162-34163, (116 [uninit]): 34164, (117-119):
34165-34167, (120 [uninit]): 34168, (121-128): 34169-34176, (129 [uninit]): 34177, (13
0-131): 34178-34179, (132-134 [uninit]): 34180-34182, (135): 34183, (136 [uninit]): 34
184, (137-139): 34185-34187, (140 [uninit]): 34188, (141): 34189, (142 [uninit]): 3419
0, (143-144): 34191-34192, (145 [uninit]): 34193, (146-149): 34194-34197, (150-151 [un
init]): 34198-34199, (152): 34200, (153 [uninit]): 34201, (154-156): 34202-34204, (157
-159 [uninit]): 34205-34207, (160): 34208, (161 [uninit]): 34209, (162-164): 34210-342
12, (165-168 [uninit]): 34213-34216, (169): 34217, (170-172 [uninit]): 34218-34220, (1
73): 34221, (174-175 [uninit]): 34222-34223, (176-177): 34224-34225, (178 [uninit]): 3
4226, (179-180): 34227-34228, (181 [uninit]): 34229, (182-183): 34230-34231, (184-186
[uninit]): 34232-34234, (187-197): 34235-34245, (198 [uninit]): 34246, (199-204): 3424
7-34252, (205 [uninit]): 34253, (206): 34254, (207 [uninit]): 34255, (208-214): 34256-
34262, (215-218 [uninit]): 34263-34266, (219): 34267, (220 [uninit]): 34268, (221-222)
: 34269-34270, (223 [uninit]): 34271, (224): 34272, (225-226 [uninit]): 34273-34274, (
227-228): 34275-34276, (229 [uninit]): 34277, (230): 34278, (231 [uninit]): 34279, (23
2): 34280, (233-234 [uninit]): 34281-34282, (235-237): 34283-34285, (238 [uninit]): 34
286, (239): 34287, (240 [uninit]): 34288, (241): 34289, (242 [uninit]): 34290, (243-24
4): 34291-34292, (245-248 [uninit]): 34293-34296, (249-253): 34297-34301, (254 [uninit
]): 34302, (255): 34303
正如你所见,这些跟ext2的相似之处在于都是连续的块,只是中间有uninit数据,传说中的数据空洞。这里的uninit到底怎么回事呢,反正我也不是很清楚,只是发现把该文件压缩,其压缩率大概在60%左右,而连续数据几乎不可压缩。

那么问题来了!
......

1. 按理说都是连续的块,但是根据测试出来的结果来看的话,连续确实比顺序的IOPS高。
2. 就算第二种请不是连续的块,但是到了Block层,根据linux内核里的IO调度来说,会根据IO请求的队列进行排序,那么按理说经过排序后的数据块也是连续的才对呢。

反正这里好多都行不通,还望各位不吝赐教!
...全文
954 3 打赏 收藏 转发到动态 举报
写回复
用AI写文章
3 条回复
切换为时间正序
请发表友善的回复…
发表回复
存储-路飞 2014-12-29
  • 打赏
  • 举报
回复
不要direct IO方式下发IO,并且测试前要清cache。即echo 3 >/proc/sys/vm/drop_caches 连续确实比顺序的IOPS高,你所谓的连续和顺序是啥意思?
cTx521 2014-11-24
  • 打赏
  • 举报
回复
谢楼上友情帮顶

4,436

社区成员

发帖
与我相关
我的任务
社区描述
Linux/Unix社区 内核源代码研究区
社区管理员
  • 内核源代码研究区社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧