Re: Some thoughts on NFS

On Wed, Feb 20, 2019 at 7:58 AM Robert Haas wrote: > On Tue, Feb 19, 2019 at 1:56 PM Andres Freund wrote: > > My point is that for iSCSC to be performant we'd need *all* the > > infrastructure we also need for direct IO *and* a *lot* more. And that > > it seems insane to invest very substantial

Re: Some thoughts on NFS

Hi, On 2019-02-20 11:25:22 +1300, Thomas Munro wrote: > This seems to make sense, and has the advantage that it uses > interfaces that exist right now. But it seems a bit like we'll have > to wait for them to finish building out the errseq_t support for NFS > to avoid various races around the

Re: Some thoughts on NFS

On Wed, Feb 20, 2019 at 5:52 AM Andres Freund wrote: > > 1. Figure out how to get the ALLOCATE command all the way through the > > stack from PostgreSQL to the remote NFS server, and know for sure that > > it really happened. On the Debian buster Linux 4.18 system I checked, > > fallocate()

Re: Some thoughts on NFS

On Tue, Feb 19, 2019 at 8:03 PM Thomas Munro wrote: > A theoretical question I thought of is whether there are any > interleavings of operations that allow a checkpoint to complete > bogusly, while a concurrent close() in a regular backend fails with > EIO for data that was included in the

Re: Some thoughts on NFS

On Tue, Feb 19, 2019 at 2:05 PM Magnus Hagander wrote: > C'mon Robert. > > Surely you know that such patches should be landed on *Fridays*, not > Thursdays. Oh, right. And preferably via airplane wifi from someplace over the Atlantic ocean, right? -- Robert Haas EnterpriseDB:

Re: Some thoughts on NFS

On Tue, Feb 19, 2019 at 7:58 PM Robert Haas wrote: > On Tue, Feb 19, 2019 at 1:56 PM Andres Freund wrote: > > My point is that for iSCSC to be performant we'd need *all* the > > infrastructure we also need for direct IO *and* a *lot* more. And that > > it seems insane to invest very substantial

Re: Some thoughts on NFS

On Tue, Feb 19, 2019 at 1:56 PM Andres Freund wrote: > My point is that for iSCSC to be performant we'd need *all* the > infrastructure we also need for direct IO *and* a *lot* more. And that > it seems insane to invest very substantial resources into developing our > own iSCSI client when we

Re: Some thoughts on NFS

Hi, On 2019-02-19 13:45:28 -0500, Robert Haas wrote: > On Tue, Feb 19, 2019 at 1:29 PM Andres Freund wrote: > > And I think it's not that likely that we'd not screw up a > > number of times implementing iSCSI ourselves - not to speak of the fact > > that that seems like an odd place to focus

Re: Some thoughts on NFS

On Tue, Feb 19, 2019 at 1:29 PM Andres Freund wrote: > > Is that a new thing? I ran across PostgreSQL-over-iSCSI a number of > > years ago and the evidence strongly suggested that it did not reliably > > report disk errors back to PostgreSQL, leading to corruption. > > How many years ago are we

Re: Some thoughts on NFS

Hi, On 2019-02-19 13:21:21 -0500, Robert Haas wrote: > On Tue, Feb 19, 2019 at 1:17 PM Andres Freund wrote: > > On 2019-02-19 16:59:35 +0100, Magnus Hagander wrote: > > > There might be a use-case for the split that you mention, absolutely, but > > > it's not going to solve the

Re: Some thoughts on NFS

On Tue, Feb 19, 2019 at 1:17 PM Andres Freund wrote: > On 2019-02-19 16:59:35 +0100, Magnus Hagander wrote: > > There might be a use-case for the split that you mention, absolutely, but > > it's not going to solve the people-who-want-NFS situation. You'd solve more > > of that by having the

Re: Some thoughts on NFS

Hi, On 2019-02-19 16:59:35 +0100, Magnus Hagander wrote: > There might be a use-case for the split that you mention, absolutely, but > it's not going to solve the people-who-want-NFS situation. You'd solve more > of that by having the middle layer speak "raw device" underneath and be > able to

Re: Some thoughts on NFS

On Tue, Feb 19, 2019 at 5:38 PM Christoph Moench-Tegeder wrote: > ## Magnus Hagander (mag...@hagander.net): > > > You'd solve more > > of that by having the middle layer speak "raw device" underneath and be > > able to sit on top of things like iSCSI (yes, really). > > Back in ye olden days we

Re: Some thoughts on NFS

On Tue, Feb 19, 2019 at 5:33 PM Tomas Vondra wrote: > > On 2/19/19 5:20 PM, Robert Haas wrote: > > On Tue, Feb 19, 2019 at 10:59 AM Magnus Hagander > wrote: > > >> There might be a use-case for the split that you mention, > >> absolutely, but it's not going to solve the people-who-want-NFS > >>

Re: Some thoughts on NFS

Hi, On 2019-02-19 20:03:05 +1300, Thomas Munro wrote: > The first is practical. Running out of diskspace (or quota) is not > all that rare (much more common that EIO from a dying disk, I'd > guess), and definitely recoverable by an administrator: just create > more space. It would be really

Re: Some thoughts on NFS

## Magnus Hagander (mag...@hagander.net): > You'd solve more > of that by having the middle layer speak "raw device" underneath and be > able to sit on top of things like iSCSI (yes, really). Back in ye olden days we called these middle layers "kernel" and "filesystem" and had that maintained

Re: Some thoughts on NFS

On Tue, Feb 19, 2019 at 10:59 AM Magnus Hagander wrote: > The only case I've run into people wanting to use postgres on NFS, the NFS > server is a big filer from netapp or hitachi or whomever. And you're not > going to be able to run something like that on top of it. Yeah. :-( It seems,

Re: Some thoughts on NFS

Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Feb 19, 2019 at 2:03 AM Thomas Munro wrote: > > How can we achieve that, without writing our > > own NFS client? > > > > Instead of writing our own NFS client, how about writing our own > network storage protocol? Imagine a

Re: Some thoughts on NFS

On 2/19/19 10:59 AM, Magnus Hagander wrote: > On Tue, Feb 19, 2019 at 4:46 PM Robert Haas > wrote: > > On Tue, Feb 19, 2019 at 2:03 AM Thomas Munro > wrote: > > How can we achieve that, without writing our > > own NFS

Re: Some thoughts on NFS

On Tue, Feb 19, 2019 at 4:46 PM Robert Haas wrote: > On Tue, Feb 19, 2019 at 2:03 AM Thomas Munro > wrote: > > How can we achieve that, without writing our > > own NFS client? > > > You'll need it :) Instead of writing our own NFS client, how about writing our own > network storage

Re: Some thoughts on NFS

On Tue, Feb 19, 2019 at 2:03 AM Thomas Munro wrote: > How can we achieve that, without writing our > own NFS client? 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

Some thoughts on NFS

Hello hackers, As discussed in various threads, PostgreSQL-on-NFS is viewed with suspicion. Perhaps others knew this already, but I first learned of the specific mechanism (or at least one of them) for corruption from Craig Ringer's writing[1] about fsync() on Linux. The problem is that close()