先说结论：只要文件是同个文件，hash是一致的。

Linux

md5sum filepath

#md5sum 01000.chunk 
ae2056ca156511f3a8223e2a4599b7bf  01000.chunk

PHP

md5_file(filename);

<?php
$file = "01000.chunk";
$md5 = md5_file($file);
var_dump($md5);
//string(32) "ae2056ca156511f3a8223e2a4599b7bf"
?>

Python

这个稍微复杂点，要自己实现，而且执行起来效率貌似也有点低。不清楚为何，按理说所有方法都要读取完整文件效率应该相差不大才对，可能是我方法不对。

import hashlib

fname = "01000.chunk"

def md5_file(filename):
    m = hashlib.md5()   #创建md5对象
    with open(filename,'rb') as fobj:
        while True:
            data = fobj.read(4096)
            if not data:
                break
            m.update(data)  #更新md5对象
    return m.hexdigest()    

hash = md5_file(fname)
print(hash, fname) 

面板底部状态灯闪红色，查看 iLO 系统诊断，提示raid1其中一个盘 FAILD, 阵列状态为 Degraded。
按提示关机替换问题的硬盘，并使阵列进入修复模式。再度发现挂载 /dev/sdb1/的 /home/目录下部分目录权限和用户描述变为 ????。
等待阵列自动修复完成后对上述问题进行修复，重启后问题处理完毕。

以下是详细备忘：

- 阅读剩余部分 -

在ssh时不小心 cat 或 tail 过 二进制文件，界面显示变成乱码。
输入什么和在什么路径都不鞥正常显示。解决办法如下

Ctrl+V 然后 Ctrl+O ， 回车

参考来源：
https://blog.csdn.net/chengxuyuanyonghu/article/details/39478447

上文core node 遭遇分叉(fork)的问题无法启动正在修复中，出块时间又逼近。决定冒险执行 core 的迁移。

原本升级迁移的也在计划中，只是这次遇到情况提前了。万幸手边设备是就绪的，除了故障的core以外内网还有3个可用的relay在正常备选。
选之前众筹拿到的 r86s，配置16G RAM 和 128 eMMC+ 500G SSD 较高，应付将来 cardano-node 升级要求提高还有充分的冗余。

准备工作

至少需要2台节点设备，建议3台。
建议有1 core 2 relay 3台，因为 迁移 relay至少得停掉其中2台，重启后如果没有relay保持在线，外部检测会认为你的pool完全脱机。

- 阅读剩余部分 -

前文再续，书接上回 听从了大佬建议。以为自己只是遇上了意外重启，草率地在 db 目录下加了 clean 标记。
之后又过了两天，发现节点又卡在 starting 状态

检查日志，看到持续报在 slot 57200220 上对 tx MEMPOOL一直报错无法处理。提示与其他节点断开重置。 (Connection reset by peer)) "(recv errored)

没空究其原因，也许遭遇了其他分叉节点的数据污染，当务之急是修正数据启动节点，因为还有不到12个小时就到 leadlog 预告的出块时间。
而该死地这个问题发生在 core node 上

- 阅读剩余部分 -