7月 122018
 

缘起

阿里云OSS比云硬盘要便宜很多,而且阿里云提供一个叫做ossfs的工具,可以将OSS挂载成本地文件系统,如果使用docker的话,也可以很容易实现一个docker volume的插件,岂不快哉!

测试几种情况:

ossfs挂载成本地文件系统后:

head -c 100 会不会很快?

测试发现,不会很快,ossfs会在/tmp目录生成一个临时文件,下载的数据远不止100字节; 所以,对于特别到的文件来讲,是受制于本地磁盘的容量的。

写入是如何实现的?写大文件时,会不会占用大量内存或本地磁盘?

写入大文件时,会在 /tmp 下创建一个临时文件(该文件打开后立即删除的,只能通过ossfs进程来看),写完后再上传到oss上; 所以,写入的文件大小同样受制于本地磁盘的容量。

ls 命令会不会快?

当目录下文件很多时,ls会非常慢。原因:ls不仅仅是一个http请求拉取文件列表,而是在拉取文件列表之后,还要通过head请求获取每个文件的元数据,假如一个目录下有几万个文件,就需要几万次请求

总结:

ossfs 将oss挂载成本地文件系统后:

  • 上传和下载时总是先写入本地磁盘 (/tmp 目录);
  • 整体读写效率较差;
  • 对于单个的大文件的情况,要考虑本地磁盘容量是否够用;
  • 下载时,虽然先下载到临时目录,但是文件并不缓存;再次访问依然需要重新下载
  • 上传时,虽然先写本地文件,应用层依然要等到文件上传完毕后才能返回(因为oss是对象存储,写入对象前必须先知道对象的大小);具体表现为,fclose触发ossfs的文件上传,但是需要等到文件上传完成后,fclose才算执行完; 对于 PHP 来讲,文件的fclose即使不显式调用,结束前也会隐式调用的
  • 所以:
    • ossfs 需要考虑适用场景
    • ossfs比较适合小文件的场景
    • ossfs不解决单个文件超过本地磁盘容量的问题;或者说,可能通过操作多个文件,而且有可能多个文件的大小之和会超过本地磁盘容量
  • 对象存储毕竟是对象存储,不能因为可以挂载到本地文件系统就变成了块儿存储
 Posted by at 下午 6:30
3月 212018
 

产品: unity500

 

实物拍照:

前面板:

上面是一个扩展柜,下面是一个主机,都是2u的设备

后面板:

从后面来看,扩展柜比主机要短一截

(话说,这布线也够烂的)

其它:

  • unity500就是最多支持500块儿盘,unity400就是最多支持400块儿盘
  • 从前面板可以看到,每个扩展柜(或主机)支持2.5英寸盘25个,(具介绍,如果是3.5英寸盘类型的盘柜的话,可以插15个)
  • unity的web管理界面常用到的功能是池子的创建、lun的创建等;
  • 不满意的地方: 每个磁盘只能属于一个池子

 Posted by at 下午 3:45
5月 112017
 

参考: http://blog.csdn.net/theorytree/article/details/6259104

说明: 显示所有支持的调度策略, 方框内的是当前启用的调度策略

查看当前系统支持的调度算法:

难道调度算法和设备本身也有关系?从下面来看,阿里云的云盘不支持任何调度策略:

但是:

值得一提的是,Anticipatory算法从Linux 2.6.33版本后,就被移除了,因为CFQ通过配置也能达到Anticipatory算法的效果。

 

查资料发现, 调度策略为 ‘none’ 的现象和阿里云虚拟机没关系,和阿里云云盘没关系,和操作系统版本也没有(直接)关系,仅仅和内核版本有关系, linux内核从3.13开始引入 blk-mq 队列机制,并在3.16得以全部实现,上面看到的非‘none’的情况,内核版本都在3.10之前,为‘none’的情况是被我手动升级内核到4.4.61 的

如何验证是否启用了blk-mq机制?可以通过查看是否存在mq目录,如下:

目录不存在,说明没有启用该机制

存在mq目录,说明使用的是blk-mq机制

参考: https://www.thomas-krenn.com/en/wiki/Linux_Multi-Queue_Block_IO_Queueing_Mechanism_(blk-mq)

参考: http://www.cnblogs.com/cobbliu/p/5389556.html

 Posted by at 上午 10:29