2012-04-28 73 views
3

场景A通过nfs共享mmap文件?

要共享的同一主机上运行的两个过程之间的存储器中的读/写块,乔mmaps从两种方法中相同的本地文件。

情形B

要共享的在两个不同的主机上运行的两个进程之间的存储器的读/写块,乔股经由主机之间NFS一个文件,然后mmaps共享来自两个进程的文件。

有没有人试过方案B?情景B中出现的哪些额外问题不适用于情景A?

+0

你可能会得到'ENODEV'。但是编写一个试图从NFS映射文件的程序比编写这个问题需要更少的击键。 – C2H5OH 2012-04-28 21:34:45

+0

@ C2H50H:为什么会返回NODEV?我很确定mmap系统调用会返回成功 - 但是这不能回答我的问题。 – 2012-04-28 21:39:25

回答

0

我想说方案B拥有各类问题(假设其工作原理在评论中所建议的)。最明显的是标准并发性问题 - 2个进程共享1个资源,没有任何形式的锁定等。这可能会导致问题...不确定NFS在这方面是否有其独特的怪癖。

假设你能找到解决的并发问题弄好了,你现在是在保持稳定的(和快速)的网络连接的依赖。显然,如果网络退出,您可能会错过一些更改。这是否重要取决于你的架构。

我的想法是这听起来像一个简单的方式来分享在不同机器上的内存块,但我不能说我听说过它正在做这让我觉得这也不是那么好。当我认为proc之间共享数据时,我认为数据库,消息或专用服务器。如果您做一个PROC主(处理并发和拥有的概念 - 即无论这家伙说的是数据的最佳副本)它可能工作...

4

MMAP将不共享数据,而无需额外的一些这种情况下,动作。

如果更改文件的mmaped部分数据的变化将只存储在内存中。直到msync或者munmap或者关闭甚至决定OS内核及其FS,它们才会被刷新到文件系统(本地或远程)。

使用NFS时,锁定和存储数据将比使用本地FS更慢。刷新超时和文件操作时间也会有所不同。

On the sister site人们说NFS可能缓存策略很差,因此将NFS服务器的I/O请求比I/O请求计数与本地FS进行比较要多得多。

2

您需要字节范围锁才能正确行为。它们在NFS> = v4.0中可用。