@juniorzhou 感觉目前应该没啥更优的解法了，普通的文件系统可能要删更久，大部分文件系统都没有对删除一堆小文件做特殊优化，每个删除都是个复杂的原子操作。除非你可以不走 linux 的文件系统，直接调用某些 gpfs 的某些接口。

的确 删除文件一直是个老大难问题
一般来说单线程 rsync 是最快的
你后台 io 够的话，试试多线程 rsync ，find 限制深度 然后用 xargs/parallel 去删

日历？重复性事件

无脑 es 吧，数据量大了 水平扩展起来也方便。
或者 Cassandra 这种。

@ZField 技术栈过于先进了, 考虑下传统的 imgui?

如果喜欢+高兴，就不算乱花

我觉得是排序导致的，把 order by 去了可能时间上会差不多。最直接办法还是看看 explain, 盲猜 in 过滤一堆数据，但是因为你最后是 datetime 排序，所以这个排序做了一个临时表去排。
理论上数据库应该是能利用索性查这个的，但是你用的数据库可能就傻傻的都查出来再排了。

技术上，wifi 的名字是 essid, 还有个类似于 mac 的 bssid.
要是软件安全性好，完全可以识别出这种攻击，但是防御效果也有限。

大部分程序员，可能对网络和文件系统接口都不熟。
现代操作系统提供的网络基本上都不会出现传输错误，现代操作系统也都会提供 seek+随机写的功能。
对于 preallocate 会有各种实现方式，不过提供的结果基本一致，也就是实现了随机写。另外，即使不依赖 seek ，也可以有 mmap 这样的方式实现随机写。
再说从网络下载到磁盘，大部分操作系统也会提供 zero-copy 或者类似 pipe 的功能，即使没有，IO 操作时基本上也是使用一个固定 buffer ，比如 64k ，不会把全部内容放到内存再操作。
再说一下状态恢复，类似数据库一样，分片的下载状态一般是单独存放，比如 aria 、flashget 或者迅雷，只有分片下载完成后再去更新状态，这样即使程序崩溃，也可以下次启动从恢复点续传。
最后补充一个极端的例子，BT 下载每次传输单元是 16KB ，难不成要创建一堆 16KB 的文件，然后完成之后再合并？从文件系统的效率角度来说，从 socket 读并且单独写入一个大文件，这里可以只需要频繁调用 read(socket) + write(fd)。 但是如果是一堆小文件，你需要频繁创建和关闭文件，这两个操作在大部分操作系统，尤其是 HDD 上的文件系统，开销会非常大，你的顺序写操作会变成随机写，同时如果你的操作系统安装了杀毒软件，杀软也会在文件关闭时进行扫描，结果就是更慢了。

一般程序员在软件设计和实现的时候，都会倾向于使用资源需求最小并且吞吐量高的方案。所以当小文件没有明显优势，而且特殊场景下资源开销和性能都有明显损耗的情况下，选择大文件是一个比较自然的方案。

类似的需求还有比如数据库，就像如果网络客户端发送了一些 INSERT ，你是把他们写入小文件然后再合并呢，还是直接放到大文件中。这里的就会有和网络下载类似的权衡，当然也有不一样的地方。

@kenvix 你以为这样的程序员是段子？他其实是认真的，就感觉没啥讨论下去的意义。

一般都是写到一个大文件吧，下载到单独文件，相当于 IO 两次，除了某些场景下，现在的 OS 对于这个没有特殊差别。
但是对于真的大文件，比如 10GB 以上的，你这种写两遍的操作会占用两倍的磁盘空间，而且对于 HDD ，一边读一边写会巨慢。
所以，这么做，单纯的是菜（不会 seek ）。

面向网盘+图片的 CMS 系统？

@Misakas 一般不会不是 8 的倍数，程序员不会自己没事找事。

collected?

@changdy 小白 allinone 吧。

@msg7086 感谢 我的网络是 T-Mobile

我是 google photos+黑群晖
因为目前 selfhosted 的照片备份（ ios+安卓）只有群晖的还算能用。