Hi, On 2019-02-19 13:21:21 -0500, Robert Haas wrote: > On Tue, Feb 19, 2019 at 1:17 PM Andres Freund <and...@anarazel.de> 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 middle layer speak "raw device" underneath and be > > > able to sit on top of things like iSCSI (yes, really). > > > > There's decent iSCSI implementations in several kernels, without the NFS > > problems. I'm not sure what we'd gain by reimplementing those? > > 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 talking? I think it's been mostly robust in the last 6-10 years, maybe? But note that the postgres + linux fsync issues would have plagued that use case just as well as it did local storage, at a likely higher incidence of failures (i.e. us forgetting to retry fsyncs in checkpoints, and linux throwing away dirty data after fsync failure would both have caused problems that aren't dependent on iSCSI). 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 development on, given that it'd basically require all the infrastructure also needed for local DIO, which'd likely gain us much more. Greetings, Andres Freund
