看戏啦，2047的弱智站长：xsden还没恢复，连公告都删了，好惨啊。

[匿名者]

https://archive.is/VyX3H

xsden还没恢复，连公告都删了，好惨啊。

[thphd]

@Wolfychan 到宜家仲未有消息

[匿名者]

新品葱、XsDen宕机原因挖掘

Hurricane Ida 8月30日袭击路易斯安那州，造成停电

这确实有可能导致品葱下线

（所以我怀疑品葱和XsDen很有可能为了省钱而跑去租DigitalOcean）

[匿名者]

都一天了看他装到什么时候

[匿名者]

thphd這腦殘除了內鬥還會幹啥？

[匿名者]

大媽降臨指點江山啦。你瑞得罪的人可多著，可別以為使出PUA的伎倆就可以叫我們閉嘴

https://xsden.info/topic/2157/迷雾通备份/24

thphd
20分鐘之前

@阿籬 喺 迷雾通备份 入面講：

@親衞隊

呢句粵文標准咩？

translated by https://yue.micblo.com/

呢句粵語標唔標準 / 呢句粤语夠唔夠標準 / 呢句粵語標準嗎

「咩」= what， 「嗎」= yes or no，所以呢度適合用「嗎」而不適合用「咩」

[匿名者]

醜態百出。這破玩意除了幾個太監捧臭腳，真覺得自己真香了？

[匿名者]

你們別瞎說，大媽已經自封為互聯網唯一真民意，大膽刁民，豈與真理作對？

https://2047.name/t/14590#157278

众所周知，新品葱用户不能投票，2047用户可以投票。迷雾通用户虽然可以投票，但是在迷雾通可以用小号刷票作弊，而2047在引入声望、信用分加权之后就无法作弊了。

新品葱有声望值，理论上可以按照声望加权投票防止作弊，但是新品葱的声望是累加式的，而品葱站长经常通过修改规则改变新用户积累声望的速度，使新用户积累同样声望付出的精力和时间比老用户多得多，这是不公平的，相当于操纵民意。而2047的声望规则无论怎么修改，最终的声望值都是从原始点赞数据中统计出来，同样的规则适用于每个用户的每一次点赞，不存在针对性打压新用户的情况，所以是公平的。

此外，由于新品葱的声望是累加式的，老用户可以通过疯狂给新用户点赞来快速提高新用户的声望，为自己提拔一批亲信，以确保在站务斗争中处于优势，这在新品葱历史上是十分常见的。而在2047，一个用户给别人点赞的权重，是与他历史点赞次数成反比的，所以如果一个人疯狂给小号点赞，虽然小号的声望会提高，但自己的点赞权重会不断下降，得不偿失，也就消除了高声望用户给小号刷赞的动机。

新到2047的用户里面，有的发言质量非常高，但这些新用户的声望不够，所以2047又引入了信用分制度，通过计算一个用户近期的声望（而不是全时的声望），除以他近期的发言数量，来评估他的发言价值。发言价值高的用户，发言机会就多，投票时信用分权重也高。

所以2047的投票，首先是按照一个用户对2047的贡献加权的，其次提供了两种权重，确保不管是已经为2047作出过大量贡献，还是未来有较高可能性为2047做出贡献的用户，他们的意见在投票结果中都能得到符合比例的体现。这在简中互联网是独一无二的。

[匿名者]

[匿名者]

他氣得很囉，咱這幾條點評2047的帖子點閱率比多數2047的帖子都多，比大媽搞搜尋排序的功力強多了，證明不是小號多就行得通，人吶，要有自知之明

[匿名者]

2047故障的頻率可比這幾個站都高，大夥兒都看在眼裡，純粹是太糊而無人在意罷了

[匿名者]

hahaha

他家磁盘坏了，估计又要倒库丢数据。嘲笑品葱膜乎xsden之后就该他自己倒霉了。

[匿名者]

啊……如果你又看到这行字
maintenance: disk failure
说明服务器依然正常工作，没有故障
但是工程师正在进行维护操作，所以无法加载网页
偶尔变成这样是正常的，不用惊慌，慌也没用
可以先去干点别的，再回来看
北京市五道口计算机技术有限公司

[匿名者]

大媽秀起了英文。

Statement From thphd

After communicating with our engineers on site, I can confirm that our server has experienced a major disk failure, which unfortunately looks quite like the one happened earlier to pincong.rocks/xsden.

Sign of failure: ~1 minute database timeout every half an hour, and as time goes on this duration gets shorter and shorter. The exact same problem happenend to pincong.rocks a few days before their catastrophic data loss. Programs like 2047 are write heavy by nature(several hundreds of GBs per day, mostly due to the hackernews ranking algorithm), and can decrease the life of a specific portion of the disk. optimizations have been added to mitigate this problem, expect more to come.

We believe having the harddrive working at elevated temperatures for an extended period of time, while rewriting a small section on the surface, have caused the surface to overheat and lost its magnetic properties(or stuff like that). After some tests we found the harddrive works just fine, can read/write at full speed, except a small section in the middle where 2047's virtual harddisk file resides. hardware checksum errors have prevented any software from reading that section.

Other than that, we're using a WD drive, and the mean life expectancy of a commercial harddrive is 3-5 years, longer for HITACHI, shorter for WD. This was a strategic mistake (we should have placed the VM on our HITACHI drives).

It will take about 48 hours to bring 2047 back online, since we have a lot of hardware replacement to be done, and a lot of checks to perform.

regarding data, this is infact the forth time we experience a catastrophic failure, the first time we lost about 10 days of data, the second and the third time we recovered without a scratch from our 10-minute backups.

10-minute backups are GREAT. but the script that was supposed to continuously copy the 10-minute backups to another safer storage stopped working some time ago, and as a result, we now only have data before 2021-09-04 23:57:10. that's about 11 days behind.

That's entirely my fault and I'm extremely sorry to have everyone of you bear the consequences.

if you registered your account within the 11 day period, you will not be able to log in. just register again. if you want your account back, we will restore it for you on a case by case basis.

threads and posts during this 11-day period will be restored from 3rd party sources. we've done that before, and we'll do it again.

if you saw a backup of your thread and post online(google cache / archive.org), save it as html (choose only html). that will be of great help later, in case we missed it during the process.

best wishes,

[匿名者]

Statement From thphd

After communicating with our engineers on site, I can confirm that our server has experienced a major disk failure, which unfortunately looks quite like the one happened earlier to pincong.rocks/xsden.

Sign of failure: ~1 minute database timeout every half an hour, and as time goes on this duration gets shorter and shorter. The exact same problem happenend to pincong.rocks a few days before their catastrophic data loss. Programs like 2047 are write heavy by nature(several hundreds of GBs per day, mostly due to the hackernews ranking algorithm), and can decrease the life of a specific portion of the disk. optimizations have been added to mitigate this problem, expect more to come.

We believe having the harddrive working at elevated temperatures for an extended period of time, while rewriting a small section on the surface, have caused the surface to overheat and lost its magnetic properties(or stuff like that). After some tests we found the harddrive works just fine, can read/write at full speed, except a small section in the middle where 2047's virtual harddisk file resides. hardware checksum errors have prevented any software from reading that section.

Other than that, we're using a WD drive, and the mean life expectancy of a commercial harddrive is 3-5 years, longer for HITACHI, shorter for WD. This was a strategic mistake (we should have placed the VM on our HITACHI drives).

It will take about 48 hours to bring 2047 back online, since we have a lot of hardware replacement to be done, and a lot of checks to perform.

regarding data, this is infact the forth time we experience a catastrophic failure, the first time we lost about 10 days of data, the second and the third time we recovered without a scratch from our 10-minute backups.

10-minute backups are GREAT. but the script that was supposed to continuously copy the 10-minute backups to another safer storage stopped working some time ago, and as a result, we now only have data before 2021-09-04 23:57:10. that's about 11 days behind.

That's entirely my fault and I'm extremely sorry to have everyone of you bear the consequences. in the future we will make our backup process more robust to more kinds of failures.

if you registered your account within the 11 day period, you will not be able to log in. just register again. if you want your account back, we will restore it for you on a case by case basis.

threads and posts during this 11-day period will be restored from 3rd party sources. we've done that before, and we'll do it again.

if you saw a backup of your thread and post online(google cache / archive.org), save it as html (choose 'only html'). that will be of great help later, in case we missed it during the process.

best wishes,

thphd

reach me via matrix: @thphd:matrix.org

2021 09 16

北京市五道口计算机技术有限公司

[thphd]

有用户私信反馈，说新品葱有人因为这件事嘲笑2047。把我也看笑了，不仅网址发不出来，帖子也被鹿儿移动到了争议对线。

[匿名者]

https://2047.name/t/15999
這腦殘挺有可能是自導自演，趁機搞一波肅清整風

https://2047.name/t/16001
呵呵，大媽這是奉旨刪帖？2047哪有什麼重要的帖子。即使有，也沒有絲毫影響性，簡直又在瞎操心了

[匿名者]

[匿名者]

字真醜，歪七扭八的

[匿名者]

訪客 喺 看戏啦，2047的弱智站长：xsden还没恢复，连公告都删了，好惨啊。 入面講：

有用户私信反馈

有用戶私信反饋（x）
全天候視姦品蔥（o）

合理解釋了2047有事沒事就故障，硬碟隨時隨地就爆炸的原因：如果thphd把花在其他社群的時間，抽出1/10關照自己的設備或伺服器，2047說不定現在還是完好如初呢

[匿名者]

绿盘也能用来跑服务器？我服了。

[匿名者]

幾條公告已被thphd隱藏起來，不顯示在首頁囉

大媽你可真丟人，塑造新的集體記憶並不會改變你的破爛水平

[匿名者]

幾條公告已被thphd隱藏起來，不顯示在首頁囉

大媽你可真丟人，塑造新的集體記憶並不會改變你的破爛水平

[匿名者]

对养猫君对葱爆的分析的分析
https://archive.is/LkZwW

首先我不认为钢铁雄心（HOI）进行的攻击是造成品葱数据丢失的原因。品葱丢失了大半年的数据，最大的可能性是服务器出现故障造成数据库损坏，责任一半在于不可抗力，一半在于品葱站长长期不自行备份数据。HOI攻击的效果是增加品葱的管理负担，占用其私信空间，但品葱大故障恐怕不能甩锅/归功于ta。

虽然养猫君的个人数字安全防护做得很完善，但他并非IT从业人士，对于架服务器办网站方面的技术分析，看的时候要在心里打个折扣。

首先，新品葱网站是云服务器而不是物理服务器（100%确定），CF之前被别人记录过IP。

• 2047的服务器在专人托管的电信机房里，很多操作没有云服务方便，uptime也没有云服务高，但是硬件配置可以随时加减，且不用担心被服务商删封（下面会详细讲）。从建站到现在2047发生过好几次宕机事故，除了第一次因为物理问题损失10天内容（且绝大部分由本人配合网友修复）以外，中间好几次都是利用备份数据直接复原，包括虚拟机都换了几次，但一般用户除了服务临时中断之外基本不会有什么感觉。物理服务器的好处就在这里：**即使遇到操作系统无法启动的严重故障，也可以打电话到机房，让工程师把硬盘拔下来、数据拷出来。**而云服务器一旦无法启动，如果跟服务商关系不好，就只能听天由命了。

  不过物理服务器并非2047的专利，创世之初，所有网站都是物理服务器的，例如acfun最开始建站的时候就是一台机械硬盘的家用PC~

• 云服务器备份麻烦，很有可能是站长这么久不备份的原因之一（2047是每10分钟全站备份一次），因为云服务器在云上，从云上把整个数据库拖下来是需要时间和带宽的（自动备份要加钱，下面会提到），以及云上没有windows（windows也要加钱），很多操作很麻烦，而品葱站长水平又低又吝啬又怕麻烦是众所周知的。

• 最早新品葱是有每周数据备份的，但公开的都是一个月前的备份，因为站长担心提供最近的备份会导致用户被社工。2020年4-7月新品葱出现站务危机，后来站长就越来越少公开备份了，估计是怕被人拿来搞破坏。in comparison，2047最近一次公布的备份是8月24号的https://github.com/thphd/2047/releases/tag/0.0.1。

既然是云服务器，就不得不提云服务器最大的优点：几乎不会故障。

• 云服务器的CPU、内存不是实体CPU、内存，而是带有冗余的虚拟CPU、内存。实体服务器关机以前，是可以把虚拟机无缝迁移到其他实体服务器上继续运行的。所以云服务器可以实现大半年不关机。

• 云服务器的硬盘不是实体硬盘，而是带有冗余校验的虚拟硬盘，基本上可以说只要机房不着火不进水，很难把数据弄丢、搞坏，所以云服务器的数据可以大半年不备份。而物理服务器必须时刻备份，否则硬盘挂掉就啥都没了，2047每10分钟备份一次正是因为是这个原因。

所以**“最大的可能性是服务器出现故障造成数据库损坏”**是不正确的。

• 但是云服务器有一种情况会把数据搞丢，那就是站长忘了给服务商续费，或者因为违反美国或者日本法律或者服务协议，被服务商终止服务，然后服务商把硬盘删掉了，因为是虚拟硬盘所以跟删文件一样方便，而且删掉之后很难找回来。品葱站长为了匿名，选择的是没有KYC的服务商，网友捐款又被他自己贪掉了（不然不会变成现在这样，要知道Vultr的付费随时自动备份功能只需多交20%费用，而品葱站长收了几千美金捐款外加法轮功广告费），所以现在出现这种问题，服务商大概率是不会开后门的。

• 2047是物理服务器，想删2047的数据，要么技术高深黑进来把所有备份删掉，要么一把火把机房烧了。而且就算机房烧了，github上也还有数据，使用GPG登陆的朋友也仍然可以登陆。

了解了云服务器和物理服务器的区别之后，我们再来看葱爆的案子：

• 钢铁雄心（HOI）给品葱站长喂紫薯布丁（发垃圾消息），是一种DoS攻击，由于品葱服务器的磁盘大小是有限的（而且非常有限），随着布丁越喂越多，磁盘剩余空间会越来越小，直到塞满，数据库无法写入。

• 数据库无法写入也就无法读出（因为读出的过程必然伴随写入，例如你看帖子会增加阅读数），网站当然就无法工作了。这时如果品葱站长重启服务器，因为开机过程也是需要写入磁盘的，磁盘空间不足可能导致开机卡死。而云服务器无法开机就连不上，也就无法进行远程操作，不像物理服务器可以直接拔硬盘读数据。这时如果站长急中生智，作出一些奇妙的误操作，就可能导致虚拟硬盘被删除。当然，也可能品葱服务器空间本来就不足了，HOI喂的补丁成了骆驼背上的最后一根稻草。

• MySQL遇到磁盘已满的情况，并不会返回DISK_FULL错误并拒绝服务，而会直接当场卡死，除非非常了解mysql工作原理，否则只能强行重启：https://dev.mysql.com/doc/refman/8.0/en/full-disk.html

• 所以另一种情况是，品葱站长强行重启了服务器，开启了数据库，数据库尝试从上一次强行重启的地方开始恢复。由于几乎所有数据库都依赖某种b+tree，而b+tree最流行的实现是leveldb（myrocks），leveldb极度依赖底层磁盘的顺序写入特性，如果底层磁盘（这个例子中是虚拟磁盘）不完全是顺序写入的（例如为了性能开启写入缓存），那么强行重启就会导致丢失最近写入的几个ldb文件，而leveldb在这种故障模式下完全无法recover（因为作者假定磁盘是强顺序写入的），使得强行重启有一定几率会导致丢失自上次启动数据库以来的所有数据。刚才已经说过，品葱服务器很可能是大半年不重启的。当然品葱的MySQL用的是什么后端我不清楚，但磁盘已满导致软件错误（而不是硬件故障）在IT界是非常常见的，运维老司机的法宝就是在每个磁盘放一个8G的空文件，如果任何原因导致磁盘已满，删掉文件就可以让服务瞬间恢复正常，然后再去花时间进一步排除问题。

所以说**“品葱大故障恐怕不能甩锅/归功于HOI”**，我觉得不合适，就目前掌握的证据，结合相关专业知识来看，我认为有30%可能性是HOI导致的，余下责任则归于品葱站长个人弃坑。当然HOI可能说谎，但同样的鹿儿也可能说谎，不应轻易下结论。

[匿名者]

品蔥故障要歸因於誰不好說，但2047故障歸因於大媽百分百沒有問題（笑

[匿名者]

太监清单
2021-09-19T09:17:28 (3451) 通音宽依 [rep=162 ts=1377] --> 阿篱
2021-09-19T09:00:27 (5208) 愛牛奶盒的人 [rep=368 ts=1540] --> 阿篱
2021-09-19T08:44:40 (5170) 首都卫队 [rep=65 ts=901] --> 阿篱
2021-09-19T08:03:26 (6874) 一只蔍兒 [rep=3 ts=547] --> 阿篱
2021-09-19T02:46:32 (5378) Anana [rep=0 ts=1430] --> 阿篱
2021-09-19T01:15:24 (2300) 刘慈欣 [rep=264 ts=1111] --> 阿篱
2021-09-19T00:32:34 (8022) peppa [rep=1 ts=5791] --> 阿篱
2021-09-19T00:03:10 (5333) 冲杯三鹿给党喝 [rep=111 ts=2730] --> 阿篱
2021-09-19T00:02:36 (7755) dellalove [rep=3 ts=740] --> 阿篱
2021-09-18T23:57:29 (5346) Wolfychan [rep=253 ts=909] --> 阿篱
2021-09-18T23:56:04 (5246) kill_ccp [rep=73 ts=1069] --> 阿篱
2021-09-18T23:55:53 (3188) 沉默的广场 [rep=204 ts=3408] --> 阿篱
2021-09-18T23:54:21 (5108) thphd [rep=813 ts=1366] --> 阿篱

[匿名者]

訪客 喺 看戏啦，2047的弱智站长：xsden还没恢复，连公告都删了，好惨啊。 入面講：

太监清单
2021-09-19T09:17:28 (3451) 通音宽依 [rep=162 ts=1377] --> 阿篱
2021-09-19T09:00:27 (5208) 愛牛奶盒的人 [rep=368 ts=1540] --> 阿篱
2021-09-19T08:44:40 (5170) 首都卫队 [rep=65 ts=901] --> 阿篱
2021-09-19T08:03:26 (6874) 一只蔍兒 [rep=3 ts=547] --> 阿篱
2021-09-19T02:46:32 (5378) Anana [rep=0 ts=1430] --> 阿篱
2021-09-19T01:15:24 (2300) 刘慈欣 [rep=264 ts=1111] --> 阿篱
2021-09-19T00:32:34 (8022) peppa [rep=1 ts=5791] --> 阿篱
2021-09-19T00:03:10 (5333) 冲杯三鹿给党喝 [rep=111 ts=2730] --> 阿篱
2021-09-19T00:02:36 (7755) dellalove [rep=3 ts=740] --> 阿篱
2021-09-18T23:57:29 (5346) Wolfychan [rep=253 ts=909] --> 阿篱
2021-09-18T23:56:04 (5246) kill_ccp [rep=73 ts=1069] --> 阿篱
2021-09-18T23:55:53 (3188) 沉默的广场 [rep=204 ts=3408] --> 阿篱
2021-09-18T23:54:21 (5108) thphd [rep=813 ts=1366] --> 阿篱

你真夠噁心的，持續反串下去有什麼好處？

[匿名者]

因为大师IT水平泰国第几啊。我暂且蒙在泰国的硬盘工厂里

[匿名者]

真夠噁心的