https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270810
--- Comment #12 from geoff...@dommett.com ---
(In reply to Rick Macklem from comment #11)
The tests showing the bug are all nfsv3. I'll try find time to repeat with
nfsv4 and report back.
The issue does not occur with nfsv2
--
You are rece
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270810
Rick Macklem changed:
What|Removed |Added
CC||rmack...@freebsd.org
--- Comment #1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270810
--- Comment #10 from geoff...@dommett.com ---
what you describe is not what happens running nfsv3
running nfsv3 the syncer seems to do this as long as the process does not exit
before it has finished, if it does the syncer stops, and all wr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270810
--- Comment #9 from Konstantin Belousov ---
(In reply to geoffrey from comment #8)
The pages sit in the local cache, and pushed to the server by syncer,
periodically. If you want to push them to server immediately, you need
to fsync(2), no
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270810
--- Comment #8 from geoff...@dommett.com ---
How is this not a bug ?
Under the circumstances described the pages are not written to the nfs server
EVER. the written data is permanently lost.
This is not an issue of a local cache since readi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270810
Konstantin Belousov changed:
What|Removed |Added
Resolution|--- |Works As Intended
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270810
--- Comment #6 from geoff...@dommett.com ---
The smallest test program that I have replicated this with is below.
When run on a linux machine the problem does not occur, when writing to the nfs
server running bsd.
When run on a bsd machine,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270810
--- Comment #5 from geoff...@dommett.com ---
update. calling msync with MS_SYNC only reduces the number of pages that fail
to be written. it does not eliminate them. The return value of msync is 0, so
the system claims that the call has succ
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270810
--- Comment #4 from geoff...@dommett.com ---
I am not suggesting that a file mapped on 2 machines is going to update in any
timely way, it would be ridiculous to suggest mmap should be a replacement for
mpi. However, when mmap is used for fi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270810
--- Comment #3 from Konstantin Belousov ---
NFS is not POSIX compliant, for many reasons besides mmap. It is inherent in
the protocol. This is not going to change.
FWIW, try to think how could reliable write-back from client to server on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270810
--- Comment #2 from geoff...@dommett.com ---
Well, most writes are updated on the server, (and all seem to be if the program
performs other activity before exiting) but pages get randomly missed if the
program exits soon after ther writes. N
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270810
Konstantin Belousov changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270810
Bug ID: 270810
Summary: munmap does not always sync the underlying file
Product: Base System
Version: 13.1-RELEASE
Hardware: amd64
OS: Any
Status: New
13 matches
Mail list logo
