- 主题:视频流的块存储技术
不要删除文件，而是复用旧文件覆盖写（比如用大家提到的mmap）
这样当磁盘写满一遍之后，就不会再有磁盘的删除和分配，也就没有碎片了
当然应用层需要做些事情，比如记录文件实际大小
【 在 bigsen (大海无量) 的大作中提到: 】
: 问题：系统收到视频流后将H.264视频存储到NAT磁盘阵列中，随着时间的增长，磁盘的碎片化比较严重，从而会导致执行存储时很慢，而视频流的接受相对较快，因此缓冲区在不断增长而导致内存耗尽。当更换磁盘或格式化后，此问题解决。请教下，针对这个问题有什么解决方案？
: 突然回想起来，好像有种方案是这样的解决的，就是在系统启动后，就先在磁盘上创建固定大小的文件，比如先创建500个，每个文件500M，从而在存真正的视频流时就提前申请好了磁盘空间，收到视频流后，可以直接打开某个文件覆盖存储。这样是不是就避免了写磁盘时因大量碎片
--
FROM 115.171.245.*
我也是这个思路，不但减少了碎片化，而且文件创建时分配磁盘空间后，循环覆盖写入的过程中不再申请磁盘空间，此时的存储时耗就只是数据写入磁盘IO的耗时了，没有了磁盘分配空间的时耗。
但还有一点不确定的是：一次新的覆盖写入是从文件起始位置write，在这个过程中系统会不会自动把文件大小清零或者随着文件的修改而变化？如果这样的话，岂不是又相当于在写入过程中重新分配磁盘空间么。
对于windows系统，预分配文件的创建以及写入接口是哪个呀？
【 在 jimmycmh 的大作中提到: 】
: 不要删除文件，而是复用旧文件覆盖写（比如用大家提到的mmap）
: 这样当磁盘写满一遍之后，就不会再有磁盘的删除和分配，也就没有碎片了
: 当然应用层需要做些事情，比如记录文件实际大小
: ...................
--
FROM 218.28.15.*
80个文件128G，不算小文件吧，一般不会导致碎片
【 在 bigsen 的大作中提到: 】
: 碎片化多是因为伴随录像文件会生成一个索引文件，这是个小文件，随着录像文件一同创建或删除。
: 将近20分钟会生成七八十个文件，总大小128个G吧。
--
FROM 221.218.211.*
索引文件几百k，可能是这个索引文件的创建删除造成的？
新系统运行没任何问题，一般都是几年后出现这种问题。
【 在 Bernstein 的大作中提到: 】
: 80个文件128G，不算小文件吧，一般不会导致碎片
:
--
FROM 218.28.15.*
windows不知道，linux上是fallocate之类的api
然后覆盖写的时候不要truncate
【 在 bigsen (大海无量) 的大作中提到: 】
: 我也是这个思路，不但减少了碎片化，而且文件创建时分配磁盘空间后，循环覆盖写入的过程中不再申请磁盘空间，此时的存储时耗就只是数据写入磁盘IO的耗时了，没有了磁盘分配空间的时耗。
: 但还有一点不确定的是：一次新的覆盖写入是从文件起始位置write，在这个过程中系统会不会自动把文件大小清零或者随着文件的修改而变化？如果这样的话，岂不是又相当于在写入过程中重新分配磁盘空间么。
: 对于windows系统，预分配文件的创建以及写入接口是哪个呀？
: ...................
--
FROM 115.171.245.*
如果你的操作的是文件，你还要考虑文件系统是如何把你的连续文件映射成连续扇区的。话说碎片化存储会拖慢整个系统的，难道不考虑ssd吗...
【 在 bigsen 的大作中提到: 】
: 问题：系统收到视频流后将H.264视频存储到NAT磁盘阵列中，随着时间的增长，磁盘的碎片化比较严重，从而会导致执行存储时很慢，而视频流的接受相对较快，因此缓冲区在不断增长而导致内存耗尽。当更换磁盘或格式化后，此问题解决。请教下，针对这个问题有什么解决方案？ 另外，关于视频流的块存储，目前的主流技术是什么？
:
: 突然回想起来，好像有种方案是这样的解决的，就是在系统启动后，就先在磁盘上创建固定大小的文件，比如先创建500个，每个文件500M，从而在存真正的视频流时就提前申请好了磁盘空间，收到视频流后，可以直接打开某个文件覆盖存储。这样是不是就避免了写磁盘时因大量碎片而导致的随机访问，提高了写入效率？以前还怀疑为什么这么干，现在想想应该就是优化存储效率的目的吧？ 这个提前创建的有大小无内容的文件怎么创建？
- 来自「最水木 for iPad Air (3rd generation)」
--
FROM 75.31.75.*
蔽司买的大华视频监控，他们做法是盘阵只存一个数据库，索引文件和视频文件都按固定大小blob扔数据库里，听他们说过文件系统用久了碎片会很多，而数据库管理增加删除能有效减少碎片。
【 在 bigsen (大海无量) 的大作中提到: 】
: 问题：系统收到视频流后将H.264视频存储到NAT磁盘阵列中，随着时间的增长，磁盘的碎片化比较严重，从而会导致执行存储时很慢，而视频流的接受相对较快，因此缓冲区在不断增长而导致内存耗尽。当更换磁盘或格式化后，此问题解决。请教下，针对这个问题有什么解决方案？ 另外，关于视频流的块存储，目前的主流技术是什么？
: 突然回想起来，好像有种方案是这样的解决的，就是在系统启动后，就先在磁盘上创建固定大小的文件，比如先创建500个，每个文件500M，从而在存真正的视频流时就提前申请好了磁盘空间，收到视频流后，可以直接打开某个文件覆盖存储。这样是不是就避免了写磁盘时因大量碎片而导致的随机访问，提高了写入效率？以前还怀疑为什么这么干，现在想想应该就是优化存储效率的目的吧？ 这个提前创建的有大小无内容的文件怎么创建？
--
FROM 123.150.181.*
不会
预分配很简单，不需要使用特定的API，直接fwrite写0，写到指定长度后fclose就OK
【 在 bigsen 的大作中提到: 】
: 我也是这个思路，不但减少了碎片化，而且文件创建时分配磁盘空间后，循环覆盖写入的过程中不再申请磁盘空间，此时的存储时耗就只是数据写入磁盘IO的耗时了，没有了磁盘分配空间的时耗。
: 但还有一点不确定的是：一次新的覆盖写入是从文件起始位置write，在这个过程中系统会不会自动把文件大小清零或者随着文件的修改而变化？如果这样的话，岂不是又相当于在写入过程中重新分配磁盘空间么。
: 对于windows系统，预分配文件的创建以及写入接口是哪个呀？
: ...................
--
FROM 123.112.19.*
是结构化数据库么？除了碎片问题，用数据库管理大的blob文件，存储效率会比文件慢点吧？
【 在 Akyrum 的大作中提到: 】
: 蔽司买的大华视频监控，他们做法是盘阵只存一个数据库，索引文件和视频文件都按固定大小blob扔数据库里，听他们说过文件系统用久了碎片会很多，而数据库管理增加删除能有效减少碎片。
--
FROM 218.28.15.*
好像是用 “w+” 模式打开往里写就行了，
写之前 fseek。
如果在当前文件的内容范围内写就是就地 overwritten，写越界以后文件size自动
增加。
【 在 bigsen (大海无量) 的大作中提到: 】
: 我也是这个思路，不但减少了碎片化，而且文件创建时分配磁盘空间后，循环覆盖写入的过程中不再申请磁盘空间，此时的存储时耗就只是数据写入磁盘IO的耗时了，没有了磁盘分配空间的时耗。
: 但还有一点不确定的是：一次新的覆盖写入是从文件起始位置write，在这个过程中系统会不会自动把文件大小清零或者随着文件的修改而变化？如果这样的话，岂不是又相当于在写入过程中重新分配磁盘空间么。
: 对于windows系统，预分配文件的创建以及写入接口是哪个呀？
: ...................
--
FROM 211.95.56.*