Re: Some thoughts on NFS

On Tue, Feb 19, 2019 at 2:03 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> How can we achieve that, without writing our
> own NFS client?

<dons crash helmet>

Instead of writing our own NFS client, how about writing our own
network storage protocol? Imagine a stripped-down postmaster process
running on the NFS server that essentially acts as a block server.
Through some sort of network chatter, it can exchange blocks with the
real postmaster running someplace else. The mini-protocol would
contain commands like READ_BLOCK, WRITE_BLOCK, EXTEND_RELATION,
FSYNC_SEGMENT, etc. - basically whatever the relevant operations at
the smgr layer are. And the user would see the remote server as a
tablespace mapped to a special smgr.

As compared with your proposal, this has both advantages and
disadvantages. The main advantage is that we aren't dependent on
being able to make NFS behave in any particular way; indeed, this type
of solution could be used not only to work around problems with NFS,
but also problems with any other network filesystem. We get to reuse
all of the work we've done to try to make local operation reliable;
the remote server can run the same code that would be run locally
whenever the master tells it to do so. And you can even imagine
trying to push more work to the remote side in some future version of
the protocol. The main disadvantage is that it doesn't help unless
you can actually run software on the remote box. If the only access
you have to the remote side is that it exposes an NFS interface, then
this sort of thing is useless. And that's probably a pretty common
scenario.

So that brings us back to your proposal. I don't know whether there's
anyway of solving the problem you postulate: "We need the server and
NFS client and libc to be of the right version and cooperate and tell
us that they have really truly reserved space." If there's not a set
of APIs that can be used to make that happen, then I don't know how we
can ever solve this problem without writing our own client. Well, I
guess we could submit patches to every libc in the world to add those
APIs. But that seems like a painful way forward.

I'm kinda glad you're thinking about this problem because I think the
unreliably of PostgreSQL on NFS is a real problem for users and kind
of a black eye for the project. However, I am not sure that I see an
easy solution in what you wrote, or in general.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company