@WXZhao 感觉是开头的哪个 magic byte 被 GPT 覆盖了。但是又不属于文件系统结构，所以没有被修复。
DiskGenius 之类的工具看看分区的 magic byte ？

@WXZhao 你都没分区，为什么用 fidsk ？我们理理事情经过：
1. 你误用 Windows 安装程序，给硬盘加了个 GPT 分区表，覆盖了 ext4 super block ，同时 GPT 自动在磁盘末尾加了个备份分区表
2. 按照论坛的建议，你用 fsck 和备用 super block 恢复了主 super block
3. 你又用 fdisk ，从备用 GPT 表恢复了主 GPT 表。这是不是又把 super block 给覆盖掉了？

@ukss 又称 super floppy 模式
一般人用硬盘是先有分区表，然后设置一到多个分区，然后再在分区上建立文件系统
Linux 允许不建分区表，直接全盘当成一个分区（不是全盘只分一个区）。直接建立文件系统。
其实 Windows 也支持这样的用法的。软盘就是这样，所以叫 super floppy 。系统自带的磁盘管理工具不允许你这样做。disk genious 第三方工具可以。Windows 也可以识别读取（如果是 Windows 支持的文件系统的话）

@villivateur 你再算一遍，看你数学老师打不打你？
而且这 1000 人又不是同时在跑下载。每个人实际使用效果远不止 3M

就算最便宜的绿盘或者 bx500,那也比机械强啊

@ScjMitsui 机械硬盘的问题从来都不在于连续读取，而在于随机读取

@ruixue 成本？我没看出这事有任何成本。不是完全在客户端实现吗？老用户可以强制下次登入改密码。
CDN 日志泄密，问题难道不是登入域名压根就不该走 CDN ？
首先，请你澄清一下你的协议。服务器储存什么形式的密码。客户端发送什么形式的密码。是否加盐。
提醒你，全加一样的盐等于不加盐。

@ruixue 脱库的问题与是否进行客户端 hash 无关
密码当然应该 hash 储存，这是没问题的
但是基于 TLS 或者 CDN 不完全可信，来证明客户端 hash 可能有益，那前提就不应该使用不可信的 CDN 。登入系统的日志属于安全日志，本来就不应该允许非安全部门访问。
事实就是没有哪个大厂的网站在使用客户端 hash 。如果客户端 hash 真的这么有效，那大厂的安全审计为何不采用？

@ruixue 如果你不信任你的 CDN ，你完全可以用独立域名处理登入。很多大网站包括银行都是这样做的。
需要更高安全性的部分，自己管理，和其他系统解耦。反正性能也不是最重要的因素，又不是每天都需要反复登入。这种系统有必要上 CDN 吗？

@FrankHB “而一旦经过任何一个常规的 hash ，甚至不需要 salt ，这种 pattern 就被完全破坏，也就直接报销了一个重要的攻击向量。”
大家都用 md5 ，只要不加盐，还不是一样？常用密码的 md5 都可以随便查表反查了。甚至包括了键盘序列加生日和手机号等常见密码组合。

社工攻击的问题根源难道不是用户复用密码？只要这点不改，那无论你做不做客户端 hash 那永远都拦不住用户被其他网站钓鱼，再钓回你的服务。

好，就算你用加盐 hash ，那你服务端存什么？楼上已经有人解释过了，这个 hash 的结果成为了实质上的密码。

问题的根源其实是，密码登录从根本上就不是高安全的鉴权方式。安全要求稍高的服务应该用 2fa+密码策略要求定期改密码。要求更高的服务应该强制智能卡公钥登录。
银行用的 USB key 。或者完全独立的电子令牌。都是基于这个原因。
我厂的生产环境就是必须智能卡登入，而且不是日常查邮件的智能卡，而且还要在专用电脑上连专用 VPN 才能连上。要是简单的密码二次 hash 就有用，我厂的安全团队是傻吗？

@ruixue 你觉得这是善意，但是这真的有益吗？
如果你后端服务器的密码库泄露了，假设你用的是前端 hash 一遍后端又 hash 一遍的做法。请问要穷举 128 位的 hash 容易还是穷举任意随机密码容易？
二次 hash 只会减小值域，不会增加熵。因为 hash 一定是单向的。

用户输入的密码就应该是明文（+TLS ） 传输

客户端 hash 没有意义。hash 后的内容成为了实际上的密码。如果我有能力 mitm 你的 tls ，我就有能力重放这个 hash 。结果上这个 hash 就是密码了。

就算服务端指定一个随机数做盐也还是没用。我可以 mitm 改掉你的客户端输入框，取得密码原文之后再加上盐来 hash ，再传给你。

以 TLS 可能失效为前提，那不就等于没有 TLS ，等于是明文？但是又想用某个办法来保护传输中数据，那不就是重新发明 TLS （或者打败 TLS ）？这就是密码学民科啊

TLS 的安全性当然需要研究，但那是专业密码学人士的问题。你作为 app 开发者，也就是 TLS 套件的用户，需要做的只有按照推荐设置配置你的 TLS 服务，然后及时更新 TLS 软件库而已。

@roufan1024 不好意思，我大学辅修就是经济学。
我只能告诉你你的问题经济学课本里都有。
关于你 3 楼的问题，建议你先学习名义利率和实际利率的差别，然后在学习一下货币的供给需求理论。

建议你学习一下宏观经济学，特别是西方经济学，别搞经济学民科。
分清楚 M0 和 M1 的区别。银行虽然持有大量的存款，但存款不属于银行，属于存款人。或者说，银行对存款人同时负有债务。存款人要求取出存款时，银行需要返还。
你的钱存入银行以后，大部分会被作为贷款借出，这个过程实际上是在创造 M1 的。这个比例叫做加乘系数。
财富也不等于钱。财富可以是各种有形无形的资产。钱只是一种交易媒介。钱是财富的一部分。

软路由是网关，对外暴露
nas 是内网服务，需要安全
你说这俩掺一起合适不合适？
要么你开虚拟机，但是这两样都不适合虚拟化，除非 pcie 直通网卡和 HBA 。

1. 可以，但是需要 arm 的软件包 /库。debian 官方源已经有很多软件了。其他一些软件需要你自己编译。另一些软件完全不支持 arm 。
2. 不需要。你要用也可以用，但是需要 arm 的 image 。原因同上。

run 了买郊区大豪斯，从源头上解决噪音问题

内存自己加就行了。怕兼容问题就全换，不要混用

@111qqz 1. 这不应该 oncall 做。邮件沟通转给对应组员即可

2.那就更应该安排专人负责。或者设计一套自动修整系统，解决一些小问题。

3. 那也分紧急不紧急。能用两天时间就说明没那么经济。oncall 第一任务是生产环境的 outage ，其次才是失败率。失败率剩下的不还是可用率嘛。真要是重要的问题，那也是老板负责，你有什么压力。

4. 那也是需要另外安排人做。我们组这种事情都是转给 pm 去解决的。因为 dev 控制不了用户爱怎么用。pm 却很需要了解用户需要什么功能。让 dev 做这个非常没效率。如果老板认识不到他的 dev 在干 support 和 pm 的活，那说明老板的工作没有做好。

5. 这就更是老板和 pm 的锅了啊。和其他组件如何交接，这是最初立项时就要商量好的事情。
缺 log ，缺工具，导致 Dev 浪费时间在 oncall 上，那就应该开发工具，保证下次遇到同类问题可以快速定位和控制影响。如果你有类似的想法，应该及时和老板反馈，商量如何解决同类问题。你看，visibility 这不就来了嘛。

oncall 的任务不是彻底解决问题，而是定位问题和恢复服务。这考的是产品整体架构，不是单人的技术水平。如果你们出了大事还没法恢复，你老板就完蛋了。

6. 和下游用户对接，这就是 tpm 的工作……

总之，oncall 事多是正常的，但是你没必要有压力。尽力而为就行了。

能干多少干多少，接不到的就不接。你们 oncall 没有 escalating queue 的吗？你接不到就让老板接。
你说的几种情况：
1. 用法咨询：写 wiki
2. 上线失败：上线期间安排专人另外 oncall 。因为上线时间是可控的，没必要依赖正常的 oncall
3. 非紧急问题安排新人去解决。反正不急，顺便给新人学习了。
4. 同样写 wiki 。你们组不是 customer facing 吧？写好基础的 troubleshoot 流程，交给客服人员处理
5. 你不帮我我也不帮你。他都不急你急什么？发邮件给老板，这是 long investigation ，让老板另外安排人
6. 让客服组去 follow up 。ticket 转给对应的问题组，交接完毕就可以走了。如果问题修完了还有其他问题，客服组会再来找你的。


总的来说，oncall 忙不过来永远是老板的问题，永远是流程的问题。你就是一打工的，尽力而为，不必紧张。

有人发过类似的事情，而且是全程：
/t/777316
/t/766730