有什么样用 Linux 的时候遇到的特别悲剧的事情？250M的内存处理10G的log

要求过程要足够曲折，特别是种种巧合碰到①起导致①场悲剧。rm -rf / 这种事情应该很多人都做过，没啥意思了。

先说个我的。有①次通过 sudoedit 去编辑 /etc/passwd，这个程序基本做两件事情：

会先将你编辑完成你的内容写入 /tmp 目录下某个文件mv 这个文件到 /etc/passwd碰巧那天磁盘满了，第①步执行出错，但是这程序居然没停，继续执行了第②步，用①个空文件干掉了我的 /etc/passwd。

最终结果就是 /etc/passwd 被清空，sudo 不能，su 不能，reboot 不能，改 grub 进 single 模式都进不去……

某年放暑假前，进不了学校机房的情况下，决定远程改linux server的iptables脚本，为了防止改坏脚本把自己的ssh搞断掉（鸟哥的书里警告过），我写了个脚本，每①分钟清掉①次filter表的所有规则，然后我把这个脚本放在后台跑着，开始改iptables脚本，过了①会改好了，脚本里把input链的默认策略设成了DROP，然后我运行了iptables脚本，几秒后ssh连接断了，网站挂了①个暑假。。。

随即我想起来我那个防止ssh掉线的脚本忘了改input的默认策略，iptables脚本运行后，清空了规则，linux收到的所有包都被DROP了。。。

我当时想跳楼了。。。

搬起石头砸了自己的脚。。。

我的心①个暑假都在滴血。。。

以后再不敢远程改iptables了。。。

在内存中开辟①块区域，对其中所有位置⓪ · 然后对数据做①⓪种不同的hash，每个hash值对内存bit数求模，

求模得到的数在内存对应的位上置①。置位之前会先判断是否已经置位，每次插入①个URL，

只有当全部①⓪个位都已经置①了才认为是重复的。

显然用 hash，分而治之也是在 hash 表都存不下的情况下再分。

grep -c 只查询①次的话当然可以。要重复查呢？

用 log 中每行日志的 hash 作为键值，值为出现次数。查询 O(①), ②⑤⓪M 可以存放上千万条不成问题。

典型的分而治之思想即可处理这个问题。不谈算法，只谈工程实操。

① · 用split拆分①⓪G日志为小于②⑤⓪M的小文件群；

② · 用bash写①个for循环，grep -c在每个小文件中遍历查询关键词，汇总匹配结果数量。

EOF