Date: Thu, 24 Sep 1998 21:36:51 -0400 (EDT) From: Luoqi Chen <luoqi@watermarkgroup.com> To: dillon@backplane.com, luoqi@watermarkgroup.com Cc: committers@FreeBSD.ORG Subject: Re: Kernel is hitting my debugging printf's Message-ID: <199809250136.VAA00121@lor.watermarkgroup.com>
next in thread | raw e-mail | index | archive | help
> :Bingo! That's it! I think this is the one that's responsible for the data loss. > :After the page is put on the page cache queue, it could be reclaimed for > :other use. The next time you write to the same disk block, the data has to be > :reread from the disk which doesn't have latest modifications. > : > :To fix this problem, you either could change to if statements to check for > :B_DELWRI bit, or clear B_RELBUF if B_DELWRI is set earlier in the function. > :I prefer the latter because it doesn't make much sense carrying the B_RELBUF > :bit around. > : > :-lq > > Ok, I will throw in clearing B_RELBUF if B_DELWRI is set just before > the VMIO buffer rundown in brelse() and let it run for a day or two > on our news box before comitting it. > > -Matt > > There's still one thing I don't quite understand. The code path to reach vfs_vmio_release with B_RELBUF set should be, vm_fault()->vnode_getpages()->ffs_getpages()->ffs_read()->brelse() If the page is still in a B_DELWRI buffer, it should be also in the vm object, the page fault should be a soft fault, the only thing vm_fault() needs to do is to insert the page into the physical map, no io should be required. There is still something not quite right, this fix shouldn't be needed at all. But for now, I think it will plug the hole. -lq
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809250136.VAA00121>