V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  gridsah  ›  全部回复第 1 页 / 共 8 页
回复总数  146
1  2  3  4  5  6  7  8  
@scruel 主盘读压力大的时候就有从盘读。就观察我的设备来看,极少触发从盘读。
@scruel
创建共享文件夹时,勾选哈希完整性选项后,没有上 raid1 ,DSM 不会自我修复。遇到 data corruption 时 log center 会有记录,需要用户介入。

从盘有损坏,只有 DSM 在读到从盘上的损坏的数据的时候,才会从主盘拿好的数据来修从盘上的数据。mdadm 使 i/o 尽可能发生在主盘上,所以从盘上的数据损坏才不容易被发现。并不是不修从盘上的数据。
@scruel 有,一定要设置。“启用数据总和检查码以实现高级数据完整性”就是 self-healing 在 web ui 上的开关。
总结一下,HPE MicroServer Gen8 板载 USB2.0 旁边的 EMMC 损坏之后可以自己更换。操作教程很容易找。

尽量买带锡珠的 EMMC 芯片,如果 Gen8 还准备用很久,推荐买 2-3 片,这玩意以后还不知道好不好找。

买个植锡网,带 153 接口的就行。如果芯片没换好需要自己重新植锡,新手植锡很麻烦,但只要不大力出奇迹、不用烙铁长时间烫主板和芯片就很难翻车。

换好芯片之后开机,在 iLO Web 上面重新格式化 EMMC 。如果提示无法格式化,那就说明要么 EMMC 没买对型号,要么换芯片的时候没有焊牢。

接着进入 BIOS 把序列号和 product key 填好,断开电源线,重新上电。这时候 iLO 就不报 EMMC 有问题了。

(换 EMMC 之后,序列号和 product id 信息就丢了。到 BIOS 里面重新填一遍,让 BIOS 把信息写到 EMMC 里面,iLO 才能读到)

最后去下载 SPP ,用 SPP 里面的 USB 启动盘制作工具,把 IP ISO 刷入 U 盘,插到 Gen8 上,开机,把 IP 刷入 EMMC 。整个修复过程就完成了。
我从 BIOS 里面输入了纸片上的序列号和 product id ,iLO 里面显示一切正常了。但是 SPP 和 IP 还是无法从 ventoy 启动。

接着,我意识到一个问题,我需要纠正,换 emmc 之前,我从 iLO 远程挂载了 SPP ,一切正常,换 emmc 之后也可以这样启动 SPP ;换 emmc 之前我从 ventoy 启动了 IP ,报 error flashing the nvram ,换 emmc 之后也可以从 ventoy 启动 IP ,也是报 error flashing the nvram 。从这个角度看来,我换 emmc 之前和之后机器的行为没有变化。

我在换 emmc 之后才把 SPP 和 IP 用惠普的 bootable USB 制作工具写到 U 盘里,才确定可以正常使用 U 盘里的 SPP 和 IP 。

现在,这台 Gen8 上除了固件 Intelligent Platform Abstraction Data 的版本号显示 0.00 以外 (从其他用户图中的固件号应该是 1.01),机器的表现和 emmc 损坏之前已经没有区别了。

PS: 我在惠普的论坛上看到有人也无法从 ventoy 或 rufus 制作的 U 盘启动 SPP 和 IP 。也有人升级固件以后 Intelligent Platform Abstraction Data 显示的版本降低了,惠普官方对升级固件后 Intelligent Platform Abstraction Data 版本号变低的人说,Intelligent Platform Abstraction Data 这个固件无法被独立更新,显示的版本号独立存储,不从真正的固件里面取,版本号不对不影响固件功能。

算是修(折)复(腾)成功了。
@tylinux #1 我手边没有可以读 emmc 的设备,怎么确定有没有 boot0 分区,以及,丢没丢东西?

@ckzx #2 额,我的本意是买个料板,到手才发现主板没坏,只是 emmc 寿命到了,然后折腾起来完全不心疼

@8675bc86 #4 我记得这玩意当初德亚海淘才 1300 左右吧,4000 就离大谱。
目前的情况是,我在 BIOS 里面找到了改序列号和 product id 的地方,用纸片上的值填进去了,iLO4 里面已经可以正常看到序列号和 product id 了。

但还是无法启动 ventoy 里面的 SPP 和 IP 。固件信息里面 Intelligent Platform Abstraction Data 的版本号还是 0.00 。
2023-11-18 16:48:34 +08:00
回复了 ShadowPower 创建的主题 Windows 求推荐 Windows 下的图片查看器
irfanview +1 https://www.irfanview.com/ 我用好长时间了
2023-11-06 16:42:26 +08:00
回复了 gridsah 创建的主题 程序员 从最近发的一个工单来吐槽一下群晖的技术支持和 DSM Raid
@rio 质疑群晖、理解群晖、购买群晖
2023-11-05 22:58:47 +08:00
回复了 gridsah 创建的主题 程序员 从最近发的一个工单来吐槽一下群晖的技术支持和 DSM Raid
@geniussoft @Ericality @sentinelK @chronos @xianghou @GooMS @lifanxi @Damenly1 @Rorysky @zhughs @WuSiYu @dd102 @rio

我用黑群晖虚拟机模拟了一下的静默错误,发现我之前的观点和结论是错的,群晖真的实现了让 btrfs 利用 mdadm 中的热冗余数据来修复自己的数据的功能。

我新开了个帖子 https://www.v2ex.com/t/988874

模拟的过程在这里:

https://note.lishouzhong.com/article/wiki/%E7%BE%A4%E6%99%96%E7%9B%B8%E5%85%B3.html
2023-11-04 22:09:50 +08:00
回复了 gridsah 创建的主题 程序员 从最近发的一个工单来吐槽一下群晖的技术支持和 DSM Raid
@rio 对对对,我想找的就是这样的实测文章。我刚在我的 HPE Gen10 上用公版的 mdadm+lvm+btrfs 测完,结论是不魔改组件的话 fs scrub+md scrub 不能修复静默错误。

等我参考这篇文章测一下群晖的行为。非常感谢,帮大忙了!!
2023-10-29 18:35:12 +08:00
回复了 PerryHe 创建的主题 Ubuntu 求推荐本地文件夹同步工具
@PerryHe rsync+inotify +1 或者 rsync+cron

另外,你 rsync 用的不熟悉的话,我翻译了 rsync 命令的文档,你可以参考
( rsync daemon 和 rsync.conf 的文档还没来得及翻译

https://note.lishouzhong.com/article/translation/rsync%20v3.2.7%20man(1)%20page%20%E4%B8%AD%E6%96%87%E8%AF%91%E6%9C%AC.html
2023-10-29 18:31:57 +08:00
回复了 catfly 创建的主题 Google 有人知道靠谱的 gv 商家吗?
gv...... 是什么

@baiduyixia 你不是一个人
2023-10-29 18:08:44 +08:00
回复了 gridsah 创建的主题 程序员 从最近发的一个工单来吐槽一下群晖的技术支持和 DSM Raid
@leang521 核心数据需要冷备+定期检查 checksum ,反正我的核心数据也就不到 2T ,其中 1T 还是视频文件。

@liprais 我没给钱,因为个人用户没有那样的 support

我待的公司也不用群晖,否则我说不定能蹭一下公司的 business support

@WuSiYu 看来咱们两个的理解相同
2023-10-29 00:29:30 +08:00
回复了 gridsah 创建的主题 程序员 从最近发的一个工单来吐槽一下群晖的技术支持和 DSM Raid
@Admstor 淦,群晖的看到了请联系我付宣传费。

群晖和 bat 不一样的吧,bat 是使用开源工具来自己写服务,然后用自己写的服务挣钱;群晖是把开源服务组合起来卖钱。我问 bat 他们的服务咋写的他们肯定不会告诉我,但是如果我问他们的东西怎么用的话,就很合理;迁移到群晖这边就是,我问群晖的客服你们这个保证客户数据完整性的功能是用什么组合出来的,我觉得没啥不合理的。hhhhhh

倒是,群晖的客服和 bat 的客服一比,确实算很不错了。
2023-10-29 00:24:16 +08:00
回复了 gridsah 创建的主题 程序员 从最近发的一个工单来吐槽一下群晖的技术支持和 DSM Raid
@Rorysky 我对那句话的认识是,群晖的这个人不理解 mdadm scrub 的行为,导致他认为 mdadm scrub 可以修复 btrfs 中的 data corruption 。

因为,我对所有组件的预期行为是它们在未被群晖定制的情况下的行为,对于未定制过的 mdadm 来说,mdadm scrub 修复的是 mdadm 自身的问题,无法修复 mdadm 之上的 btrfs 中的问题。而我问他 mdadm scrub 凭什么可以修复 btrfs 中的问题,群晖的人又不告诉我原因。所以我有理由怀疑群晖的这个人并不理解这些组件的协同工作方式;或者从恶意的角度出发,他理解,但是他以为我是竞争对手的人而不想告诉我。

另外,你想要讨论,我欢迎,请发表你的观点与逻辑链,不要针对我如何来输出。你可以说我的观点是错的、浅显、片面,然后开始反驳,而不能说感觉我如何如何,你要再这么说的话我就要开喷了。
2023-10-28 23:03:02 +08:00
回复了 gridsah 创建的主题 程序员 从最近发的一个工单来吐槽一下群晖的技术支持和 DSM Raid
@sorsens #46 你连基本的判断能力都没有吗,上来就喷,已拉黑
2023-10-28 22:07:48 +08:00
回复了 gridsah 创建的主题 程序员 从最近发的一个工单来吐槽一下群晖的技术支持和 DSM Raid
@zhughs #43 说白了,我就是想知道群晖如何处理 silent data corruption......

关于第二点,文件的逻辑位置转硬盘物理位置,组合数据之后重新计算 checksum 的这个功能,在 #23 我估了一下这个功能的工作量,很大,不论是对 madm, btrfs 还是对 DSM 底层的魔改,工作量都很大。我觉得群晖不大可能费力气做这个功能。

我在 存储池 -> 全局设置 里面找到了这个功能。关于这个功能,我只在 https://www.reddit.com/r/synology/comments/qy51ba/what_the_heck_is_fast_repair/?rdt=53246 看到了关于这个功能的猜测,还未被证实。如果帖子里的描述是真的的话,那说不准群晖还真的做了这个功能。

但从回帖的内容来看,我和这帮老外的想法一样,群晖不会花大功夫来研究和定制底层。

而且我认为我的看法是对的,因为,从我这个角度来看,至少他们在升级组件的时候不会有额外的,因兼容群晖自己的魔改而产生的额外的工作量;而且不魔改组件也意味着,不会受人事的限制,不用担心会魔改的员工走了以后没人接活儿的问题。
2023-10-28 21:37:05 +08:00
回复了 gridsah 创建的主题 程序员 从最近发的一个工单来吐槽一下群晖的技术支持和 DSM Raid
@zhughs #43 关于第二点 '提供 mdadm 的 fast repair 功能' 这个有链接或者出处吗,我想看看

第三点,我看 btrfs 文档说的是 The whole metadata block has a checksum stored inline in the b-tree node header, each data block has a detached checksum stored in the checksum tree.

按照你的理解方式: 文档逗号以前的意思是,metadata extent 有一个和 metadata 数据存储在一起的 checksum 。data block has a detached checksum stored in the checksum tree 的意思是所有的数据的 checksum ,不论是 metadata 还是 data ,都存储在一个共用的 checksum tree 里面,所以 metadata 的 checksum 有两份。

但是,文档里说,metadata 也有两份,如果按照你这个思路继续推,两份 metadata 有两份跟随 metadata extent 的 checksum ,然后 checksum tree 里还有一份 metadata 的 checksum ,那这不就有三份 metadata 的 checksum 了吗。

所以我认为,文档中逗号以前的意思是,metadata extent 有一个和 metadata 数据存储在一起的 checksum ,不变。但是 metadata 有两份,因此 metadata 的 checksum 有两份。data block has a detached checksum stored in the checksum tree 的意思是所有的 data extent (不包括 metadata extent) 的 checksum 存储在一个独立的 checksum tree 中。所以 data extent 有一份数据 (一个 data extent tree) 和一份 checksum (一个 checksum tree)。

emmmmm 我觉得我的理解比较合理。
1  2  3  4  5  6  7  8  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5795 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 49ms · UTC 03:17 · PVG 11:17 · LAX 19:17 · JFK 22:17
Developed with CodeLauncher
♥ Do have faith in what you're doing.