Re: Fwd: Re: A new look at old NFS readdir() problems?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Jan 2, 2025 at 3:49 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm still of the opinion that the best thing to do is disclaim
>> safety of storing a database on NFS.

> If we're going to disclaim support for NFS, it would certainly be
> better to do that clearly and with reasons than otherwise. However, I
> suspect a substantial number of users will still use NFS and then
> blame us when it doesn't work; or alternatively say that our software
> sucks because it doesn't work on NFS. Neither of which are very nice
> outcomes.

Are you prepared to buy into "we will make every bit of code that uses
readdir() proof against arbitrary lies from readdir()"? I'm not:
I cannot see how to do that in any but the simplest cases -- rmtree()
being about the simplest. Even if we had a bulletproof design in
mind, it's pretty hard to believe that future patches would apply
it every time. I think it's inevitable that we'd have bugs like
"sometimes not every file gets fsync'd", which would be impossible
to find until someone's data gets eaten, and maybe still impossible
to find afterwards.

(To be clear: if this is how FreeBSD acts, then I'm afraid we already
do have such bugs. The rmtree case is just easier to observe than a
missed fsync.)

regards, tom lane