wxf666

@festoney8 #54 Windows 不至于每写一个文件，就强制落盘 $MFT 吧，应该能内存里缓存一段时间，积攒一堆新文件元数据，再一起写入，平摊随机读写成本，转换成大量顺序读写？

其实感觉楼主应该换新方法存储了，否则 NTFS 每次读写都得额外访问 $MFT 、校检权限、杀毒软件放行等，严重拖慢速度，特别是像现在的备份 / 迁移时。。

感觉巨量小文件存数据库里更优，元数据很轻量，且能和文件内容放在一起，减少几次随机 IO （视索引 B+ 树层级而定）。还不用 4K 簇对齐，更充分利用硬盘空间。备份 / 迁移时，还能大文件整体拷贝，吃满硬盘性能。

如果实在要以文件系统形式，对其他程序提供服务，可以用些 fuse 手段。或者参考 RamDisk 它们怎么实现文件读写接口的，它们随机读写文件速度极快，因此这个抽象层应该不会有太多性能损耗。。

现在 AI 这么发达，上述应该不难实现，论坛首页都一堆讨论 AI 的 v 友，请教下他们，或者出点小钱让其帮忙，应该就行了。。

@festoney8 对呀，就是一个个文件去读，但按照它们内容在硬盘上顺序，去决定文件列表，这样磁头就不需要频繁移动，减少寻道时间，尽量将随机读写，转化成顺序读写了吧？

实在不行，就手动分析物理硬盘上，每个 4K 块数据，属于哪个文件的呗。然后顺序读取分区，提取数据缓存在内存里，哪个文件缓存完了（可能有文件碎片成多个 4K 块），就写入到另一个硬盘里。

别说不可能，各种碎片整理软件，都能知道每个文件每一块碎片，在物理磁盘上的偏移范围。。

@laminux29 #36 数据库在随机读写里面的小文件时快不了多少，但作为一个大文件，整体去备份 / 迁移，应该能顺序读取，吃满硬盘性能吧。。

另外，你觉得 35 楼说的「分析文件内容在硬盘上的分布，按硬盘顺序读取，减少磁头频繁移动，从而节省大量时间。若文件有碎片，在内存里缓存一部分，读完整再写入」原理，是可行的吗？

@jiagm #33 fastcopy 有利用 35 楼说的「分析文件内容在硬盘上的分布，按硬盘顺序读取，减少磁头频繁移动，从而节省大量时间。若文件有碎片，在内存里缓存一部分，读完整再写入」原理吗？感觉是真的可行的。。

如果还没有这样的软件，感觉楼主 @CristianoRonaldo 可以找论坛里，那帮用 AI 很厉害的人，快速写个这样的小工具出来用？

@festoney8 诶，你们觉得，要是能顺序读取硬盘的同时，分析出是哪个文件的内容（应该能通过 MFT 主文件表，获取每个文件数据分布范围吧）。若该文件读完整了，就写入到另一个硬盘里，应该会快很多吧。。

或者，获得所有文件数据分布范围后，按在硬盘上的顺序，依次读取这些文件，磁头不用频繁移动，也能节省大量时间？（也算近乎顺序读取了？）

这种巨量小文件，存进数据库里（如 SQLite ），是不是会好很多？

NTFS 文件系统，每个文件元数据（文件名、长度、时间、权限等）起码占 1KB （ MFT 主文件表里），文件内容还要浪费 < 4KB 用于簇对齐。读写文件还得经过复杂的权限校检、杀毒软件放行等。（估计 WinPE 里会快些）

数据库就轻量很多。8 年前 SQLite [测试]( https://sqlite.org/fasterthanfs.html )，随机读写 10KB 小文件，比文件系统快 35%，节省 20% 空间。转移/备份时也是顺序读写，能全速吃满硬盘。。

@vopsoft x265 是软件，h265 才是一种编码格式。。

有啥地方有分享 TMPGEnc 压制的片子吗？看看画质如何。。

@1una @Tink 现在有啥压 av1 / vvc 的地方吗？我看有人几百 MB 压一部 1080p 《哪吒 2 》，画质就很不错了。。现在存储涨价挺猛的，要是能屯这种小体积高质量的片，还是很舒服的。。


@ntedshen 噢，说十年前是吧。。当时主流 CPU 是 i5-4590 之类的吗。。看了下 r23 跑分，多核是 7945HX 在 65W 功耗时 10%。。加上当年 x265 估计优化还不行，压 1080p 确实可能都还有点吃力吧。。

@ntedshen 现在电脑压缩视频不算吃力吧，两三千 7945HX 整机，65W 功耗，几小时就能 x265 veryslow 压一部 4K 电影了吧。。

@vopsoft 除了 av1 / vvc 外，真的还有比 x265 压的又快又小又好的软件吗。。