- 主题:视频流的块存储技术
问题:系统收到视频流后将H.264视频存储到NAT磁盘阵列中,随着时间的增长,磁盘的碎片化比较严重,从而会导致执行存储时很慢,而视频流的接受相对较快,因此缓冲区在不断增长而导致内存耗尽。当更换磁盘或格式化后,此问题解决。请教下,针对这个问题有什么解决方案? 另外,关于视频流的块存储,目前的主流技术是什么?
突然回想起来,好像有种方案是这样的解决的,就是在系统启动后,就先在磁盘上创建固定大小的文件,比如先创建500个,每个文件500M,从而在存真正的视频流时就提前申请好了磁盘空间,收到视频流后,可以直接打开某个文件覆盖存储。这样是不是就避免了写磁盘时因大量碎片而导致的随机访问,提高了写入效率?以前还怀疑为什么这么干,现在想想应该就是优化存储效率的目的吧? 这个提前创建的有大小无内容的文件怎么创建?
--
FROM 218.28.15.*
能多解释几句?
【 在 poikilotherm 的大作中提到: 】
: fallocate
来自 Redmi K20 Pro
--
FROM 171.8.223.*
先用fallocate创建大文件,然后open该文件,再向文件循环写入,这样是不是可以极大的提高写入效率呢?
【 在 poikilotherm 的大作中提到: 】
: fallocate
来自 Redmi K20 Pro
--
FROM 171.8.223.*
这个成本就高多了吧。并且我存储的是视频,最高效率的存储方式首推块存储,如果只用到块存储的话,上ceph的必要性就不大了吧。感觉ceph主要对象存储比较强大,更适合于云端那种分布式文件存储。
【 在 MyWorkLife 的大作中提到: 】
: 你需要的是ceph这样的存储系统,了解下吧
:
--
FROM 218.28.15.*
不懂,查了下mmap的概念,“而系统会自动回写脏页面到对应的文件磁盘上”这句话没明白。
我的应用需求是可执行程序已块的方式进行视频流存储,这个mmap貌似多用于web?
【 在 babam 的大作中提到: 】
: lz想问的是 mmap?
: 的碎片化比较严重,从而会导致执行存储时很慢,而视频流的接受相对较快,因此缓冲
: 区在不断增长而导致内存耗尽。当更换磁盘或格式化后,此问题解决。请教下,针对这
: ...................
--
FROM 218.28.15.*
碎片化多是因为伴随录像文件会生成一个索引文件,这是个小文件,随着录像文件一同创建或删除。
将近20分钟会生成七八十个文件,总大小128个G吧。
【 在 Bernstein 的大作中提到: 】
: 为什么会碎片化呢?一般来说,除非有很多小文件才会碎片化。
: 每分钟多少数据量?
: 一个基本的办法是累积到一定的数据量再写出到磁盘,但操作系统一般都有缓存,可以保证这一点
: ...................
--
FROM 218.28.15.*
我也是这个思路,不但减少了碎片化,而且文件创建时分配磁盘空间后,循环覆盖写入的过程中不再申请磁盘空间,此时的存储时耗就只是数据写入磁盘IO的耗时了,没有了磁盘分配空间的时耗。
但还有一点不确定的是:一次新的覆盖写入是从文件起始位置write,在这个过程中系统会不会自动把文件大小清零或者随着文件的修改而变化?如果这样的话,岂不是又相当于在写入过程中重新分配磁盘空间么。
对于windows系统,预分配文件的创建以及写入接口是哪个呀?
【 在 jimmycmh 的大作中提到: 】
: 不要删除文件,而是复用旧文件覆盖写(比如用大家提到的mmap)
: 这样当磁盘写满一遍之后,就不会再有磁盘的删除和分配,也就没有碎片了
: 当然应用层需要做些事情,比如记录文件实际大小
: ...................
--
FROM 218.28.15.*
索引文件几百k,可能是这个索引文件的创建删除造成的?
新系统运行没任何问题,一般都是几年后出现这种问题。
【 在 Bernstein 的大作中提到: 】
: 80个文件128G,不算小文件吧,一般不会导致碎片
:
--
FROM 218.28.15.*
是结构化数据库么?除了碎片问题,用数据库管理大的blob文件,存储效率会比文件慢点吧?
【 在 Akyrum 的大作中提到: 】
: 蔽司买的大华视频监控,他们做法是盘阵只存一个数据库,索引文件和视频文件都按固定大小blob扔数据库里,听他们说过文件系统用久了碎片会很多,而数据库管理增加删除能有效减少碎片。
--
FROM 218.28.15.*