On Tue, Jan 30, 2018 at 08:31:05AM +0100, Reindl Harald wrote:
Am 30.01.2018 um 08:25 schrieb Petr Pisar:
On 2018-01-29, J. Bruce Fields bfields@redhat.com wrote:
The file create isn't allowed to return until the server has created the file and the change has actually reached disk.
Why is there such a requirement? This is not true for local file systems. This is why fsync() exists
pretty simply because on the NFS server side the whole VFS layer sits again and without "async" in the export you need a way to rely on "the stuff i wrote to the network ended on the filesystem on the other end"
If I need reliability, I issue fsync from the client process, client VFS passes it to the NFS client, NFS client translates it into NFS COMMIT message, sends it to the NFS server, NFS server translates it back to fsync, pass it to the server VFS and from there to the local file system driver.
I don't understand why NFS should be reliable by default.
-- Petr
On 30 January 2018 at 03:12, Petr Pisar ppisar@redhat.com wrote:
On Tue, Jan 30, 2018 at 08:31:05AM +0100, Reindl Harald wrote:
Am 30.01.2018 um 08:25 schrieb Petr Pisar:
On 2018-01-29, J. Bruce Fields bfields@redhat.com wrote:
The file create isn't allowed to return until the server has created
the
file and the change has actually reached disk.
Why is there such a requirement? This is not true for local file systems. This is why fsync() exists
pretty simply because on the NFS server side the whole VFS layer sits
again
and without "async" in the export you need a way to rely on "the stuff i wrote to the network ended on the filesystem on the other end"
If I need reliability, I issue fsync from the client process, client VFS passes it to the NFS client, NFS client translates it into NFS COMMIT message, sends it to the NFS server, NFS server translates it back to fsync, pass it to the server VFS and from there to the local file system driver.
I don't understand why NFS should be reliable by default.
I think it has to do with what NFS 'promises' to try to do and that it is built for dealing with multiple clients being able to read to the same areas at the same time. Having it so that you have unreliable writes tends to make multiple clients get different versions of the data. It was also originally written to work on UDP for the original sets so that means that you have to be more careful. While NFSv4 is a tcp it had other requirements which makes reliability what the standard requires.
In the end, networks are not 100% reliable and corner cases not small percentage. Things get weird at times and the client and server may need to resend various commands. If the client VFS assumes that the data was already written, it may drop that from its cache or allow other changes which the server won't allow. If another process on that system looks for the data in that file because its VFS says its there, but the data is not in cache and the system asks the server before the server has written.. it can get garbage. [I expect there are special deadlocks and such which could happen.]
[For some reason I think this is a common question I have seen with NFS and various developers over the years. I may be parroting poorly something written by others.]
-
Petr Pisar -
Stephen John Smoogen