- 主题:视频流的块存储技术
不要删除文件，而是复用旧文件覆盖写（比如用大家提到的mmap）
这样当磁盘写满一遍之后，就不会再有磁盘的删除和分配，也就没有碎片了
当然应用层需要做些事情，比如记录文件实际大小
【 在 bigsen (大海无量) 的大作中提到: 】
: 问题：系统收到视频流后将H.264视频存储到NAT磁盘阵列中，随着时间的增长，磁盘的碎片化比较严重，从而会导致执行存储时很慢，而视频流的接受相对较快，因此缓冲区在不断增长而导致内存耗尽。当更换磁盘或格式化后，此问题解决。请教下，针对这个问题有什么解决方案？
: 突然回想起来，好像有种方案是这样的解决的，就是在系统启动后，就先在磁盘上创建固定大小的文件，比如先创建500个，每个文件500M，从而在存真正的视频流时就提前申请好了磁盘空间，收到视频流后，可以直接打开某个文件覆盖存储。这样是不是就避免了写磁盘时因大量碎片
--
FROM 115.171.245.*
windows不知道，linux上是fallocate之类的api
然后覆盖写的时候不要truncate
【 在 bigsen (大海无量) 的大作中提到: 】
: 我也是这个思路，不但减少了碎片化，而且文件创建时分配磁盘空间后，循环覆盖写入的过程中不再申请磁盘空间，此时的存储时耗就只是数据写入磁盘IO的耗时了，没有了磁盘分配空间的时耗。
: 但还有一点不确定的是：一次新的覆盖写入是从文件起始位置write，在这个过程中系统会不会自动把文件大小清零或者随着文件的修改而变化？如果这样的话，岂不是又相当于在写入过程中重新分配磁盘空间么。
: 对于windows系统，预分配文件的创建以及写入接口是哪个呀？
: ...................
--
FROM 115.171.245.*
数据库写性能一般都很好，视频存储又是写多读少，用数据库还真挺合适的
【 在 bigsen (大海无量) 的大作中提到: 】
: 是结构化数据库么？除了碎片问题，用数据库管理大的blob文件，存储效率会比文件慢点吧？
--
FROM 61.148.16.*