Date: Mon, 05 Jul 2021 11:45:18 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256936 --- Comment #9 from Agata <firstname.lastname@example.org> --- First of all: MooseFS uses FUSE 3 whenever possible (it checks what is available on the system it's compiled on and uses that). And we do try to use all the new options and mechanisms available to us. But there is no mechanism that would prevent a network file system that uses cache from overwriting some data if two processes on two machines write to the same cached block at the same time. I mean, once both kernels have modified the same frame of cache and want to push the dirty frame to the filesystem, there is no way to automagically update/correct one of them. The only solution is to not use cache at all (BTW, MooseFS client mounted with -o mfscachemode=DIRECT, which translates to each open always setting direct_io to 1 and keep_cache to 0, still triggers the "buggy" message). But not using cache at all is not a solution, because of performance. The commit you mentioned invalidates all cache, even the dirty frames. IMHO dirty frames should never be invalidated. It should be left to the users/programmers to make sure they don't modify the same area of the file (use locks etc.) Or we can say goodbye to any caching... The script I posted as an example is not "correct", in that it doesn't use locks, but it's my (programmer's) "fault" that data gets written to a file without control, not the _network_ filesystem's. -- You are receiving this mail because: You are the assignee for the bug.