chapel - 并行写入 NFS 支持的文件

Question

更新:我让每个节点写入一个单独的文件，当单独的文件连接在一起时，结果是正确的。我还更新了代码以尝试在每次写入单个记录后进行 channel 刷新和文件同步，但现在节点 0 和 1 之间仍然存在问题。如果我在节点 0 开始其 coforall 循环迭代之前让节点 0 休眠几秒钟，记录就会正确无误。否则，节点 0 记录的最后几百个字节似乎会被 NULL 字节可靠地覆盖，直到节点 1 记录的开头。节点 1 和节点 2、节点 2 和节点 3 之间的问题似乎不再出现。

此外，如果我抑制节点 0 或节点 1 写入，我会看到来自未抑制节点的完整记录已正确写入文件。在节点 1 被抑制的情况下，我在文件中看到 9,997 100B 记录(或 999,700)正确字节后跟 NULL 字节，节点 1 的抑制记录将去往该文件。在节点 0 被抑制的情况下，我在文件中看到恰好 999,700 个 NULL 字节，之后节点 1 的记录开始。

---

原帖:

我正在尝试解决从不同节点并行写入磁盘上支持 NFS 的共享文件的问题。目前，我怀疑 NFS 服务器上写入磁盘的方式有问题。

我正在调整使用 pwrite 写入文件协调 block 的 MPI+C 代码。如果我尝试让 Chapel 中的等效语言环境写入 coforall 循环内的文件，我最终会弄乱节点边界周围的文件位 - 通常是最后几百个字节每个节点的数据都是乱码。但是，如果我只有一个语言环境遍历所有语言环境的数据并写入，数据就会正确输出。也就是说，我使用相同的数据结构来计算偏移量，但只有区域设置 0 寻找该偏移量并执行写入。

我已验证每个语言环境运行的文件中的偏移量不重叠，并且我为每个任务使用一个 channel ，从 on loc do block 中定义，因此任务不共享单个 channel 。

从不同区域设置写入文件是否存在已知问题？许多文档使这看起来似乎是安全的，但未经证实的猜测似乎表明文件内容缓存存在问题；在检查不正确的数据时，不正确的位似乎是程序开始时该位置文件中的原始数据。

我在下面包含了相关例程，以防您轻松发现我遗漏的内容。为了制作这个系列，我将 coforall loc in Locales 和 on loc do block 转换为 for j in 0..numLocales-1 循环，并将 here.id 替换为 j。请让我知道还有什么可以帮助弄清这件事的真相。谢谢!

proc write_share_of_data(data_filename: string, ref record_blocks) throws {

    coforall loc in Locales {
        on loc do {

            var data_file: file = open(data_filename, iomode.cwr);
            var data_writer = data_file.writer(kind=ionative, locking=false);
            var line: [1..100] uint(8);

            const indices = record_blocks[here.id].D;

            var local_record_offset = + reduce record_blocks[0..here.id-1].D.size;

            writeln("Loc ", here.id, ": record offset is ", local_record_offset);

            var local_bytes_offset = terarec.terarec_width_disk * local_record_offset;

            data_writer.seek(start=local_bytes_offset);

            for i in indices {
                var write_rec: terarec_t = record_blocks[here.id].records[i];
                line[1..10] = write_rec.key;
                line[11..98] = write_rec.value;
                line[99] = 13;  // \r
                line[100] = 10;  // \n
                data_writer.write(line);
                lines_written += 1;
            }

            data_file.fsync();
            data_writer.close();
            data_file.close();
        }
    }

    return;

}

Answer 1

在此处添加解决了我的特定问题的答案，但它没有解释所见行为。我最终将外循环从 coforall loc in Locales 更改为 for loc in Locales。这不是一个太大的问题，因为无论如何它都是写入一个文件 - 我怀疑多个语言环境实际上可以在所有尝试并发写入 NFS 服务器上的单个文件方面取得很大进展。因此，更改仍然允许节点将它们在本地拥有的数据写入 NFS，而不是强制节点 0 代表所有区域收集数据然后写入数据。这相当于仅向写入操作添加空闲时间，该空闲时间与前一个节点完成写入时 Locale 0 在其他节点上启动远程任务所花费的时间相称，这对于手头的应用程序来说不是问题。