Date: Sun, 13 May 2018 21:41:20 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Ryan Stone <rysto32@gmail.com> Cc: "freebsd-fs@freebsd.org" <fs@freebsd.org> Subject: Re: "NFS append race" Message-ID: <20180513184120.GY6887@kib.kiev.ua> In-Reply-To: <CAFMmRNy%2Bk1swbmQRWWs_wsACcM7EkLKQS9dtfikzFCH3pXSQaA@mail.gmail.com> References: <CAFMmRNy%2Bk1swbmQRWWs_wsACcM7EkLKQS9dtfikzFCH3pXSQaA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 13, 2018 at 11:07:05AM -0400, Ryan Stone wrote: > I have a 11.1-RELEASE client mounting an NFS directory from a > 12-CURRENT server. I'm doing a buildworld right now on it, with the > src dir mounted on a local drive on the client and the objdir on the > NFS mount. I'm seeing the following printed to the console every few > minutes: > > > NFS append race @10000:4040 > NFS append race @10000:4040 > NFS append race @10000:564 > NFS append race @10000:564 > > > The "10000" is never changes, but the number after the : is always > different (except that the exact same message will repeat once within > a second of the first message) > > What does this mean? Is it something to be concerned about? I remember that nfsiods threads do not lock the vnode when performing the async io. This seems to be the most feasible explanation for the race. Basically, kernel tracks the dirty regions in the buffers, and apparently the append write covers less region that the currently recorder dirty region. If truncation occured while there is still a scheduled nfsiod write, then the write would re-dirty the truncated range. I suspect that this is mostly innocent. Of course, we should start locking the vnodes in nfsiod.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180513184120.GY6887>