NFS calculation of max commit size
kostikbel at gmail.com
Wed Aug 17 13:52:38 UTC 2011
On Wed, Aug 17, 2011 at 09:15:15AM -0400, Rick Macklem wrote:
> I think that any fraction of hibufspace should be sufficient to avoid
> the deadlock. Also, since the buffer cache code doesn't use vnode locking
> these days, I'm not even sure if write backs are blocked by the wrire
> vnode op in progress. (ie. I'm not sure the deadlock it originally fixed
> would still happen without it.)
bufdaemon definitely acquires vnode lock when flushing dirty buffer,
this was a problem on its own. I think you refer to the nfsiod operation.
There is another op that is performed without holding the vnode lock
consistently from (old)nfs code, namely, truncation. It would be useful
to fix this. Please see r188386.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20110817/deeacde1/attachment.pgp
More information about the freebsd-fs