不用看这个，有个 commit 会改进 bounds check elimination，这个会回滚的

w3c school 垃圾
MDN 好

福冈大学有一个 NTP 服务器跑了二十几年，最近也撑不住了

http://enog.jp/wp-content/uploads/2017/10/20171027_ENOG47_tanizaki.pdf

@SuperMild DDR3。不多说。

@tiancaiamao go 用函数式完全没问题。还有类型系统，哪个语言没有类型系统？

@yao990 这个可以恢复 vg，但是 xfs 有没有被你的 xfs_repair 之类的命令破坏就不知道了。如果你没动过文件系统，那恢复 vg 是肯定没问题的，问题就在于你用了 xfs_repair 之类的…………

恢复旧 vg 前把现在的 vg 也备份一下，存到其他地方，以备恢复……

多余

@yao990 lvreduce 之后想要回滚，应该用这个方法： https://www.techrepublic.com/blog/linux-and-open-source/use-vgcfgbackup-and-vgcfgrestore-to-back-up-metadata-on-lvm/

@yao990 如果你能找到人现场帮你修，或者可以救回来。或者先放着不要动，等以后你知道怎么修了，再看看有没有救，不要再这里动一下那里动一下了……

@yao990 放弃吧，以后重要文件做好备份

update numbers
set used = true
where num = (
select num from numbers
where not used
order by random()
limit 1
)
returning num

主见都没有，创什么业
别人想到的，别人自己就动手做了，何必和你讲，嫌对手太少？

lvextend 可能用到了其他的 extent，所以读不到原来的数据。如果使用原来的 extent，可能可以修复
应该先缩小文件系统，再缩小 lv 的，但你直接缩小 lv 了
lvextend 应该指定原来的 pv 和 extent，但你可能没有指定
lvm 是可以恢复原先的配置的，在 /etc/lvm/backup, archive 都有记录，而你选择了 lvextend ……
挂载之后 ls 出现错误，这时候就不应该做任何操作，但你还执行了 xfs_repair 等等，很可能造成进一步的破坏
连续几次失误……

都是 ffmpeg / libav 的壳，随便

不够是因为某些程序，例如 chrome，有内存泄漏，这种是 1024G 都不够漏的

你不说是什么程序，完全判断不了性质