问在繁忙的构建节点上通过NFS托管Yocto SSTATE_MIRROR --这是个坏主意吗？

EN

很难确切地说你看到了一些分析数据的问题，但是我有一些观察和建议。

您在正确的轨道上使用NFS作为CI节点之间的sstate缓存，但我建议再走一步。与其让一个节点作为sstate缓存的“守护者”，让所有其他节点使用它作为镜像，我建议让每个节点将公共NFS共享直接挂载为SSTATE_DIR。这允许所有节点在构建过程中读取和写入缓存，并且在更新所需的sstate对象方面做得更好。如果只有一个节点填充缓存，则不太可能包含其他构建所需的所有对象。

此外，我建议NFS服务器是一个持久服务器，而不是绑定到Jenkins代理。这给你带来了一些好处：

1. 这意味着您可以将硬件资源专用于缓存，而不必让它们与正在进行的Jenkins构建竞争。
2. 您可以放置一个简单的HTTP服务器前端，为缓存文件提供服务。这样做可以让您的开发人员工作站将该HTTP服务器设置为他们的SSTATE_MIRROR，从而直接受益于您的Jenkins节点产生的缓存。如果您这样做是正确的，开发人员应该能够复制以前由Jenkins完全从sstate构建的构建，这可以节省大量的本地构建时间。即使您没有完全复制Jenkins以前做过的构建，您仍然可以从sstate中提取大量的数据。

最后要检查的是是否启用了哈希等价。哈希等价是一种构建加速技术，它允许bitbake检测元数据何时更改到通常会导致其重新构建的配方，从而产生与以前构建的sstate对象相同的输出，而不是从sstate构建它。默认情况下，从Yocto3.0 (codename )开始启用此功能。如果基础结构中没有运行哈希等效服务器，bitbake将在构建期间启动本地服务器。但是，在像Jenkins节点这样的分布式环境中工作时，这可能会导致一些问题，因为哈希等价性很大程度上取决于sstate缓存的内容。如果每个节点在本地运行它自己的哈希等价服务器，则它们可以得到发散的sstate散列(特别是当CI节点是瞬态的，而本地的哈希等价数据库丢失时)，这可能导致更多的sstate丢失。解决方案是要么运行一个哈希等效服务器(bitbake附带一个)并将所有CI节点指向它，要么通过设置：BB_SIGNATURE_HANDLER = "OEBasicHash"完全禁用哈希等价。