相册应用扫描大容量硬盘时因内存分配失败崩溃（附 dmesg 证据）
环境信息
- 系统版本：FNOS（内核 6.18.18-trim）
- 相册版本：trim.photos v0.9.3
- 硬件：i3-8100 / Z370 / 16GB DDR4 / GTX 1060 6GB
- 存储：vol2（12TB 西数）+ vol00 外挂两块 14TB（WUH721414ALE6L0、TOSHIBA MG07ACA14TE）
- 照片总量：约 80 万张
问题描述
相册应用在扫描包含大量文件的目录时，必定崩溃并显示"找不到文件夹"，随后自动重启，再次扫描再次崩溃，进入死循环。
经过逐步排查，定位到问题的根本原因是应用一次性向系统申请约 22.4GB 内存，远超物理内存总量（16GB），被内核拒绝后进程直接退出。
复现步骤
- 清空相册数据库，重新启用应用
- 添加小目录（如几百张照片的文件夹）→ 扫描正常完成
- 添加大目录（14TB 外挂盘根目录，含数十万文件）→ 应用在开始遍历目录树后约 1-2 分钟内崩溃
关键日志证据
dmesg 内核日志（多次出现完全相同的分配请求）：
[Tue May 5 00:02:28 2026] __vm_enough_memory: pid: 8214, comm: trim-photos, bytes: 24020779008 not enough memory for the allocation
[Tue May 5 01:25:07 2026] __vm_enough_memory: pid: 13471, comm: trim-photos, bytes: 24020779008 not enough memory for the allocation
[Tue May 5 08:39:39 2026] __vm_enough_memory: pid: 23723, comm: trim-photos, bytes: 24020779008 not enough memory for the allocation
[Tue May 5 09:12:51 2026] __vm_enough_memory: pid: 66716, comm: trim-photos, bytes: 24020779008 not enough memory for the allocation
[Tue May 5 11:00:29 2026] __vm_enough_memory: pid: 78900, comm: trim-photos, bytes: 24020779008 not enough memory for the allocation
[Tue May 5 11:02:04 2026] __vm_enough_memory: pid: 100174, comm: trim-photos, bytes: 24020779008 not enough memory for the allocation
每一次都是请求 24,020,779,008 字节（约 22.4GB），系统只有 16GB 物理内存，分配必然失败。
应用 error.log 中在崩溃时刻（11:02:26）没有任何错误输出，说明进程是被系统直接终止，并非应用内部捕获的异常。
eventlogger 事件日志：
错误,ALL,2026-05-05 11:02:26,system,应用 相册 异常退出
分析
从日志来看，trim-photos 在遍历目录树 / 构建文件列表时，可能将所有待处理文件信息一次性加载到内存，而非分批流式处理。当文件数量达到数十万级别时，内存需求暴增至 22GB+，导致 16GB 甚至 32GB 内存的机器都无法承受。
建议开发团队排查扫描逻辑中的内存分配策略，考虑对大目录做分页/流式遍历处理。
临时规避方法
目前只能通过拆分目录（不将整块大容量硬盘根目录直接添加，而是逐个添加子目录）来规避，但对于文件量大的用户来说并不现实。
诉求
希望官方早日解决此BUG，专业场景且有大量应用数据情况下使用飞牛OS的用户正在逐渐增加，想必这种场景以后触发的会越来越多。之前已经反馈过一次并且提交了日志，但官方在帖子下回复后不了了之，这次请朋友找到了日志中的问题点，希望官方能尽快修复。如需联系可在飞牛fnOS粉丝群648找我，昵称：陌上。
