On Sun, Oct 18, 2020 at 05:59:11PM +0900, Rin Okuyama wrote: > On 2020/10/18 2:25, Anthony Mallet wrote: > > I made some progress on this, and could apparently fix something. See > > attached a sample script that reliably reproduces the issue. > > > > To summarize: when the script is run on the NFS client, changes in the > > sqlite database do appear on the NFS client, but do not appear on > > the server. > > > > As Chuck suggested in another e-mail, reverting uvm_bio.c to previous 1.121 > > $NetBSD: uvm_bio.c,v 1.121 2020/07/09 09:24:32 rin Exp $ > > appears to fix the issue (at least the test script was working 3 times > > in a row while it always failed with uvm_bio.c:1.222). > > Thank you very much for providing test case. I can reproduce the > problem on amd64 and i386. I've reverted that commit.
I'm still running a September 17 kernel, and I see rare NFS corruption. Basically, I'm rezipping a lot of zip archives (~2TB) that are on NFS and four of them had blocks of 0 bytes afterwards, not much. For the ones I kept, the corruption is about 3k each (3413 bytes in one case, 3160 in the other). Could there be another NetBSD NFS bug here, or is that just random noise? (The NFS server is a Linux RAID). Thomas