引用:

原帖由 sunix. 于 2014-11-18 15:08 发表


这叫物奴，通常是因为真实生活中很失败，只能在某一物体或品牌上找到寄托和存在感，所以有人要是敢说那东西一点不好就好比杀了他亲妈。
战区的几个极端索索，还有周围的那些极端崇拜偶像的都是这种病

请问你这种冒充书记的又是什么奴？

引用:

原帖由 ff_cactus 于 2014-11-18 15:23 发表

我还以为你有多高明的解释呢。那为何400MB以前，每秒速度还是不断提升的，照你的意思应该，在缓存没写满之前，速度应该是恒定的呀。

读写速度跟文件大小是相关的，如果你连这个常识都不懂就不要随便发表高论了

自己用atto benchmark测一下你的硬盘看是不是速度恒定？

知识面贫乏不是错，但是出来现就不对了

楼主和HKEPC都在瞎分析，这个表现和Linux的Page cache一点关系都没有。这个测试的结果相当明显，原因也很简单，熟悉SSD的一眼就能看出来，这明显是用TLC的iPhone使用了数据压缩加速技术。早期SSD上常用，当时以SandForce主控为代表，现在的SSD似乎不太用这个技术了。

数据压缩加速对全0数据具有极强的加速效果，但是对随机数据毫无作用。从这个测试的一些结果来看，iPhone在TLC的压缩加速上可能动用了主处理器和主内存，而不是像SSD那样用SSD上的主控来做这个处理。结果就是存储的时候占用主处理器和主存，而且写入太快太大的时候会来不及压缩导致性能暴跌。

[ 本帖最后由 xphi 于 2014-11-18 16:02 编辑 ]

引用:

原帖由 dboy99 于 2014-11-18 15:46 发表


读写速度跟文件大小是相关的，如果你连这个常识都不懂就不要随便发表高论了

自己用atto benchmark测一下你的硬盘看是不是速度恒定？

知识面贫乏不是错，但是出来现就不对了

[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0219152 s, 478 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=20
20+0 records in
20+0 records out
20971520 bytes (21 MB) copied, 0.0415999 s, 504 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=30
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 0.0620917 s, 507 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=40
40+0 records in
40+0 records out
41943040 bytes (42 MB) copied, 0.0821948 s, 510 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=50
50+0 records in
50+0 records out
52428800 bytes (52 MB) copied, 0.102611 s, 511 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=60
60+0 records in
60+0 records out
62914560 bytes (63 MB) copied, 0.122361 s, 514 MB/s

你能解释下为什么速度变化如此之小吗？

引用:

原帖由 xphi 于 2014-11-18 15:56 发表
楼主和HKEPC都在瞎分析，这个表现和Linux的Page cache一点关系都没有。这个测试的结果相当明显，原因也很简单，熟悉SSD的一眼就能看出来，这明显是用TLC的iPhone使用了数据压缩加速技术。早期SSD上常用，当时以SandF ...

把数据压缩一下有什么好处？ 为什么只在SSD上做压缩，而发展了这么多年的普通硬盘上没采用过？

引用:

原帖由 ff_cactus 于 2014-11-18 16:02 发表

[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0219152 s, 478 MB/s
[root@workstation ~]# dd if=/dev/ze ...

bs=1024K这个参数控制写入块大小，从头到尾都是1024k所以速度也差不多

我能说你是个xx么，这么低级的问题都要反复问

引用:

原帖由 xphi 于 2014-11-18 15:56 发表
楼主和HKEPC都在瞎分析，这个表现和Linux的Page cache一点关系都没有。这个测试的结果相当明显，原因也很简单，熟悉SSD的一眼就能看出来，这明显是用TLC的iPhone使用了数据压缩加速技术。早期SSD上常用，当时以SandF ...

我擦，这是我今天看到的第二个神论了，可以跟虚拟内存大神的神论相媲美

引用:

原帖由 dboy99 于 2014-11-18 16:10 发表


bs=1024K这个参数控制写入块大小，从头到尾都是1024k所以速度也差不多

我能说你是个xx么，这么低级的问题都要反复问

count从10变到60你眼睛瞎啦看不到吗？ 看你还要装逼到什么时候。

引用:

原帖由 ff_cactus 于 2014-11-18 16:08 发表

把数据压缩一下有什么好处？ 为什么只在SSD上做压缩，而发展了这么多年的普通硬盘上没采用过？

Sandforce的压缩加速又不是什么神秘技术，11年前后透明压缩的各种分析文章到处都是，你就不能自己找点资料读一下？

引用:

原帖由 ff_cactus 于 2014-11-18 16:17 发表

count从10变到60你眼睛瞎啦看不到吗？ 看你还要装逼到什么时候。

小文件写一百遍还是小文件，你的逻辑我是越来越看不懂了

引用:

原帖由 ff_cactus 于 2014-11-18 16:02 发表

[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0219152 s, 478 MB/s
[root@workstation ~]# dd if=/dev/ze ...

你就算完全不懂存储好歹也看看原版HKEPC的截图，看看别人的dd命令是怎么写的……

引用:

原帖由 dboy99 于 2014-11-18 16:20 发表


小文件写一百遍还是小文件，你的逻辑我是越来越看不懂了

吓死了， 看来完全不在一个档次，你还是消停一边凉快去吧。

引用:

原帖由 dboy99 于 2014-11-18 16:11 发表


我擦，这是我今天看到的第二个神论了，可以跟虚拟内存大神的神论相媲美

我看你是喷糊涂了吧。

引用:

原帖由 xphi 于 2014-11-18 15:56 发表
楼主和HKEPC都在瞎分析，这个表现和Linux的Page cache一点关系都没有。这个测试的结果相当明显，原因也很简单，熟悉SSD的一眼就能看出来，这明显是用TLC的iPhone使用了数据压缩加速技术。早期SSD上常用，当时以SandF ...

不能解释全0最后2个测试tlc的速度下降 和 内存的区别。
这个应该是明显的cache大小在tlc和mlc上不同而造成的。
至于有没有压缩...如果有cache的话这点速度应该没必要用压缩。

引用:

原帖由 xphi 于 2014-11-18 16:21 发表


你就算完全不懂存储好歹也看看原版HKEPC的截图，看看别人的dd命令是怎么写的……

没啥区别，只不过人家是指数性增加写入量，我是线性增加写入量。